Auto-login and connection info
This page covers what the people who deploy your template see and click: the Launch button and the web addresses behind it, signing them straight into your app, the connection details on each copy's dashboard, and the instructions an AI assistant reads.
All of it is under the template's Configuration tab, and all of it needs a redeploy of existing copies to take effect.
Proxy services and the Launch button
A proxy service publishes a port inside the machine as an HTTPS web address on every copy, automatically. Use it for the app your template exists to run — a web interface, an admin console, an API.
Add them under Exposure & lifetime → Proxy services → Add service.
| Field | What it is |
|---|---|
| name | A label for the service |
| port | The port your app listens on inside the machine |
| app protocol | What your app speaks inside the machine: http or https. Visitors always get HTTPS either way. |
| prefix / suffix | Optional text added before or after the copy's id in the address, so two services on one copy get different addresses |
| subdomain | Optional: put every copy under one sub-zone instead, e.g. copy-id.myapp.platform-domain |
| custom domain | Let each deployer attach one of their own verified domains instead of the platform address |
| ignore backend TLS errors | For https apps using a self-signed certificate |
Each copy gets its own address on the platform's domain, with the certificate handled for you.
The first service powers the Launch button. When someone clicks Launch on their copy, it opens that service's address. Put your main app first.
Proxy services are yours as the author — every copy gets them. HTTP proxies (a deployer feature you can unlock) let each deployer map extra ports to their own domains. See Publishing ports.
Auto-login
Auto-login signs a visitor straight into your app when they click Launch — no login screen. Add one adapter per proxy service port under Auto-login → Add adapter.
Choose the mode that matches how your app logs people in:
| Mode | Use it when your app… | You fill in |
|---|---|---|
| form (POST a login form) | Has a normal login page | login path, method (POST or GET), body (form-encoded or JSON), Login fields — one name=value per line — and the Session cookies it sets, comma-separated |
| basic (HTTP Basic auth) | Asks with the browser's own username/password prompt | username and password |
| token_query (token in URL) | Accepts a token in the address, like ?access_token= | token field and token param |
Values can use placeholders, filled in for each copy when it is deployed:
| Placeholder | Filled with |
|---|---|
{username} | The copy's login user |
{cspassword} | The copy's code-server password |
{email} | The deployer's email address |
For example, a form login might use:
user={username}
password={cspassword}
The browser code editor signs people in automatically already — don't add an adapter for it.
Auto-login only works if your app accepts the credentials you send. Set your app up so its login matches what the placeholders fill in — for example, by setting its password from the same value when the machine starts.
Connection info
The rows shown on each copy's dashboard — addresses, usernames, passwords, commands. Edit them under Connection info.
- Add row — each row has a type (Text, Password or Code), a label and a value.
- Reorder rows with the arrows.
- The
{…}button on a row inserts a placeholder. - Student preview below shows how the rows look, with sample values.
- Reset to defaults puts back the standard rows. Saving an empty list does the same.
| Placeholder | Shows |
|---|---|
Lab IP {ip} | The copy's address |
VPN IP {ip:wg0} | Its address on the private tunnel |
Internal IP {ip:eth0} | Its internal address |
Login user {username} | The login user |
Login password {password} | The login password |
App port {port} | The app's port |
Code-server URL {csurl} | The browser code editor's address |
Code-server password {cspassword} | Its password |
Instance id {instanceid} | The copy's id |
Lab id {labid} | The lab's id |
Use the Password type for anything secret.
PROMPT.md: instructions for AI assistants
Every new template gets a PROMPT.md file in the Files tab. It holds
instructions an AI assistant receives when it works in a copy of your template
through MCP: what the lab is for, where things live, how to run and
restart the app, and what not to touch.
Keep it short and concrete — an assistant reads it before doing anything.
Each deployer can override it for their own copy with the lab's Agent Prompt
setting. An empty Agent Prompt falls back to your PROMPT.md. See
Lab settings.
Like any file edit, changing PROMPT.md means a rebuild.
Next
- Build and deploy — rebuild and redeploy to apply these
- Connect an AI assistant — how assistants use
PROMPT.md