Configuration

How settings work#

Everything is set with environment variables. With Docker Compose they come from a file named .env next to docker-compose.yml:

cp .env.example .env            # on your computer
cp .env.server.example .env     # on a public server
docker compose up -d            # after every change

Without a .env file the defaults below apply — the Studio works out of the box. With plain docker run, pass them as -e NAME=value. Several things can also be changed on the website by an administrator (registration, certificates, AI providers); what is set there wins over the file.

Website and accounts#

The AI#

Limits#

Servers of projects#

Websites and HTTPS#

How these fit together: Server & HTTPS.

WordPress#

Database#

The image contains its own database (MariaDB). It is created at the first start, its password is generated, and it has no network port — there is nothing to configure.

docker compose exec studio studio-db status
docker compose exec studio studio-db list            # the Studio's and the WordPress sites' databases
docker compose exec studio studio-db shell           # an SQL prompt
docker compose exec -T studio studio-db dump --all > all.sql

Building the image#

These apply to docker compose build (or up --build):

What is not in the image#

Three things are downloaded by each installation from their official sources instead of being shipped:

• Claude Code is Anthropic's proprietary software. The Studio downloads the official package at the first start; every person uses it with their own account under Anthropic's terms.
• The Android SDK is installed once an administrator accepted Google's license (Admin → Android SDK, or ANDROID_SDK_ACCEPT_LICENSE=yes for unattended setups).
• WordPress is downloaded from wordpress.org when a site is set up, so every site starts with the current release.

The software the image does contain, and its licenses: docs/LICENSES.md.

Security model#

• One Linux account per user. The AI, terminals, git, the Studio tools and every file access of a user run as that account. One user's AI cannot read another user's projects or logins.
• No server secrets in user processes — they get a short list of environment variables, nothing else.
• Previews and project servers are sandboxed in the browser: they run in an opaque origin and never see the Studio's login cookie.
• Websites are separate: served on their own ports and origins, from releases nobody can change afterwards. A domain belongs to one website and never to the Studio itself.
• WordPress: a site's PHP runs as its owner, confined to the project folder, without shell functions; uploads never execute; each site's database account sees only its own database.
• Accounts: registration is closed by default, logins are rate-limited, and the first account from outside the private network needs a setup code from the server log.
• The container runs with no-new-privileges, a process limit and a bounded log.

The Studio gives its users an AI that runs commands. Give accounts to people you would give a shell on that machine — and keep the image, WordPress sites and their plugins up to date.

More detail: docs/ARCHITECTURE.md. Found a problem? Security policy.

For developers#

• Architecture — how the server, the sandbox, the AI integration, websites and WordPress work
• Building Studio software — the contract the creative tools follow
• Tools · Packs · Skills

cd server && npm install && npm run build      # the API server (TypeScript)
cd web && npm install && npm run dev           # the website on :5173, proxied to a Studio on :8080