Build and deploy

By the end of this page you will have built your template, deployed a running copy of it, and know how to roll a change out — or back.

1. Build & validate

Open the template and go to the Build & validate tab.

Control	What it does
Build & validate	Checks the template, then builds it into an image
Validate only	Runs the checks without building — quick feedback while you edit
No cache	Builds every step from scratch instead of reusing earlier results. Use it when a build seems to be using stale downloads.

What validation checks

Before anything is built, the template is checked in phases:

1. The configuration is well-formed.
2. The Dockerfile — a usable base image and package manager.
3. code-server is installed and has a user to run as.
4. The VPN plumbing is in place.
5. Bind mounts point only at safe locations.

Findings are listed with a severity. Errors block the build — you'll see Validation failed — fix the errors before building. Warnings are advice; the build goes ahead.

Build progress

While it builds, a progress bar shows how far through it is and which step is running. The full output streams to the Server Logs terminal at the bottom of the page. When it finishes you get Build complete — or Build failed with the reason, and the log shows the detail.

Only one build runs per template at a time (A build is already running for this template), and you can run a limited number of builds at once across all your templates.

The post-build checks

After a successful build, the platform checks two things. The results appear as badges in the editor banner.

Check	If it fails
VPN	Copies cannot be deployed with the VPN. Deploys are refused with a message telling you to fix the image and rebuild, or switch the template to internal-only.
code-server	The browser code editor is marked missing

2. Deploy a copy

Go to the Deployments tab and click Deploy. The Deploy a copy dialog is the same one used for extra labs: a name, the login user, shared or isolated storage, and SSH keys.

The dialog tells you how many of your lab slots you are using. Copies count against your plan's limits like any other lab.

The deploy log streams in the Server Logs terminal. When it finishes you get Deployment ready — open the copy's dashboard from the list — or Deployment failed with a pointer to the deploy log.

Deploying from the editor needs a paid plan

Deploying copies of templates requires a paid plan.

Common messages:

Message	Meaning
Build this template first — only built templates can be deployed.	Run Build & validate first
Edits are pending a rebuild — Deploy runs the last built version	You changed something since the last build. The copy gets the older build.
This template is not published for deployment yet (still in alpha/draft).	Someone else's template that is still in alpha

The Deployments tab lists every copy, in list or card view, each linking to its own dashboard.

3. Roll out a change

1. Edit the template and save.
2. If the change needs a rebuild (see When a change takes effect), run Build & validate.
3. Redeploy each copy. Copies built from an older version show an update available badge — its tooltip names the new version.

A copy never updates by itself. Redeploying keeps its home directory, like any redeploy.

Versions

The Versions tab records every save, build, restore and publish. The version number in the banner goes up with each one.

Action	What it does
Diff	Shows exactly what changed in that version
Restore	Puts the template's files back as they were at that point. The status goes to draft, and the restore is itself recorded — so you can always roll forward again.

Restoring changes the template, not your copies. Rebuild and redeploy to put a restored version into service.

Git sync

Sync to my GitLab pushes the template's history to a repository in your own account on the platform's GitLab. It creates the repository the first time.

• Repo name is optional; it defaults to the template name.
• Visibility: Private (recommended), Internal or Public.
• It is one-way: the platform pushes, and never reads changes back. To bring a repository in, use Import ▾ → From Git….
• Save or build at least once first, so there is something to push.

Export

⋯ → Export as JSON downloads the template as one file, which you can bring back later with Import ▾ → From JSON….

An export is not a full backup

Text files are included up to about 8 MB in total. Larger files and binary files are listed by name only. Use Git sync to keep a fuller history.

Deleting a template

⋯ → Delete template. It is refused while copies are still running — you'll see Terminate them before deleting the template. Terminate the copies from their dashboards first.

Do it with an AI assistant

You can also do this by asking an AI assistant connected to your account — see Connect an AI assistant to set one up.

Ask	What the assistant does
“Check my template for problems without building it”	build_template as a dry run, which validates only
“Build it and tell me when it is done”	build_template, then wait_for_build
“Why did the build fail?”	template_build_log
“Deploy the first copy”	Checks readiness with template_status, then deploy_template

Builds and deploys finish in the background

Both return as soon as they are queued, so the assistant waits for the result rather than reporting success straight away. A template's very first deploy goes through deploy_template; after that it is deployed like any other lab.

Next

• Share and publish — give others access
• Running extra labs — managing the copies you deploy