Publishing

Everything you do in the builder happens in a private sandbox. It has no route to your live app, so nothing you try there can reach a customer. Publish is the single, deliberate step that changes that.

It's one button, always in the same place, and it does the whole job: checks your work, commits it, and ships it to a stage.

Annotated screenshot of the Publish panel: a "What you're shipping" section showing the workspace and a green "All changes committed" line, a checks section reading "Ready", and two destination rows — "Promote to staging" and "Ship to production" — each with the currently live version beside it. Callout: "Checks, commit, and ship — in one place."

Checks run before anything ships

Opening Publish runs a preflight against your sandbox, and it will stop you for two reasons.

You have uncommitted work. Publishing ships what's committed, so anything still loose in the sandbox simply wouldn't be included. Rather than shipping a half-version, the panel shows you exactly which files are outstanding and offers Commit & push right there — write a message, and it commits and pushes for you.

Verification failed. Pikku Studio Cloud type-checks and regenerates your project to prove it actually builds. If that fails, you get the errors and a Fix in chat button that hands them straight to the builder to sort out. If the check can't finish in time it's treated as advisory rather than a blocker — you're told, and you can ship anyway.

Missing settings block the deploy, not production

Some things can't be filled in for you — an API key, a credential for a service that's yours. When your app declares one of those, the deploy stops and lists exactly what's missing, what it's for, and where to get it, with a field to set it inline. It's a specific, fixable message rather than a deploy that succeeds and then fails at runtime in front of customers.

Choosing where it goes

Publish shows every stage your project has, with what's currently live on each:

• Promote to staging — a real deployment of your app that nobody is depending on. Check it, click around, then promote onward.
• Ship to production — the live one.

If you don't have a staging environment yet, Publish offers to add one in a click. It's worth doing: it's the difference between checking a build and hoping.

Production asks you twice

The gap between staging and production is a deliberate one.

Shipping to a non-production stage goes straight through — that's the point of it. Production doesn't. The build runs, the checks run, and then it stops and waits: this build passed its checks and is waiting for your approval to go live. Nothing reaches customers until you press Approve & ship.

So the automated checks and the human decision are two separate things, and by default the human one is yours.

Letting production go out on its own

That pause is the default, not a rule. Once you trust your checks, turn on auto-deploy for the stage and every push goes live without stopping.

It is worth doing deliberately rather than early — the pause exists to catch the thing the checks were never told to look for. Two things make it less of a leap than it sounds:

• The risky releases still stop. Even with auto-deploy on, a release waits for you if it is missing settings it needs, or if it would drop a table. The cases where a mistake is permanent are exactly the ones that keep asking.
• Every deploy rolls back in one click. Going out automatically is not the same as being stuck with it.

Watching it go

A deploy moves through queued → planning → building → deploying, and the panel tracks it live. When it lands you get a link straight to the live site.

If it fails, you get the build output and two ways forward: Retry, or hand the failure to the builder to read the log, find the cause, fix it and commit — so a failed deploy is a conversation rather than a dead end.

Committing isn't publishing

Worth stating plainly, because it's the thing people get wrong: a commit saves a snapshot of your work to your Git repository. Your live app carries on exactly as before. Only publishing puts anything in front of customers.

• Commit = save your work. Nothing goes live.
• Publish = ship your saved work to a stage.

For a fuller look at what changed before you commit, open the Changes view.

It's your repository, your code

Everything Pikku Studio Cloud writes goes into your Git repository as clean, standard code. There's no black box and no lock-in: hand the repo to an engineer and they'll find normal, readable code, and because Pikku Studio Cloud is built on the open-source Pikku framework you can take it and run it yourself whenever you want.

Where to go next

• Deployments — the record of every shipment, and one-click rollback.
• Stages & environments — what you're publishing to.
• Changes — review what's different before you ship it.
• Secrets — where the settings a deploy asks for are stored.