Deploying your project

Studio runs your project in a sandbox. To put it on the public internet, Deploy.

What deploying does

1. Pushes the workspace to a Git repo (your existing GitHub if linked, or a new Suzko-hosted repo).
2. Creates a Suzko Deploy project pointing at that repo.
3. Provisions any attached services Studio used (Postgres, Redis, etc.) on the Deploy side.
4. Builds + starts the container.
5. Hands you the public URL.

The deployed app is independent — the Studio workspace and the Deploy project drift apart unless you keep pushing back.

First deploy

Project toolbar → Deploy → wizard:

1. Name — becomes the Deploy project name + the auto subdomain.
2. GitHub — link an existing repo or use a Suzko-hosted one.
3. Region — pick datacenter.
4. Tier — free tier covers small things; pick higher for production traffic.
5. Deploy.

Build runs. URL goes live. Takes 2–5 minutes.

Continuing in Studio after deploy

You can. The deployed app + the Studio workspace are now two copies.

• Changes in Studio = workspace only. Not deployed until you push.
• Pushes happen on Re-deploy in Studio (does a git push + the Deploy project picks up the new commit automatically).

Continuing in your editor

Want to take it out of Studio and develop locally?

• Clone the GitHub repo Studio created.
• Open in your editor.
• Push back — Deploy redeploys automatically.

You can come back to Studio later — it'll pull the latest commit when you reopen the project.

Custom domain after deploy

Same as any Deploy project. See Custom domains.

Environment variables

Studio uses some env vars for its sandbox; deployment uses production vars from the Deploy project settings. They don't auto-sync — set production values explicitly in the Deploy project's Variables tab.

Cost after deploy

Studio billing (per-turn token cost) stops counting once you stop iterating in Studio. Deploy billing (container hours + storage) starts when the deploy runs. They're separate.