Migrate from Kamal to Temps
To move from Kamal to Temps, paste your rendered config/deploy.yml into the Temps import wizard (or pass it to the CLI), review the plan, and execute it. Kamal has no server-side API, so Temps reads the file instead of connecting to anything. It maps the service, its roles, proxy.host domain, app port, environment variables, Dockerfile build settings and database accessories to a Temps project, then deploys the image. Secret values, accessory data and volume contents stay with you to move.
Comparing the two before you move? See Temps vs Kamal.
Why this one's different
Every other supported platform has an API Temps queries live. Kamal doesn't — it's a CLI tool that runs from your machine and drives containers over SSH. There's nothing to "discover" from a running Kamal deployment beyond the config file that describes it, so the import reads config/deploy.yml instead of connecting to anything. A real kamal deploy doesn't need to have succeeded for the import to work — the file is enough.
What Temps discovers from deploy.yml
deploy.yml key | What it becomes in Temps |
|---|---|
service / image | The project and the image its deployment runs |
servers.<role> | The primary role becomes the deployment; other roles become additional deployments, each with its cmd |
proxy.host | A custom domain |
proxy.app_port | The container port |
env.clear (plus role-level env) | Environment variables |
env.secret | Environment variables marked secret, with no value |
accessories.* running a database image (PostgreSQL, MySQL/MariaDB, MongoDB, Redis) | Temps-managed services, created empty |
builder (dockerfile, context, args, target) | The build configuration, used when you link the repository |
volumes | Not imported (reported as unsupported) |
asset_path | Not imported (reported as unsupported) |
Dockerfile builds carry over: the plan records your builder settings, so once you link the Git repository Temps rebuilds the app from the same Dockerfile. Until then it runs the image named in deploy.yml. Accessories that aren't databases are not imported.
Will my data come across?
No, not automatically. Accessory passwords live in .kamal/secrets, not in deploy.yml, so Temps can't connect to your accessories and copy their data. Each database accessory becomes an empty Temps-managed service, and the plan tells you to dump it with kamal accessory exec <accessory> 'pg_dump …' (or the MySQL or MongoDB equivalent) and restore the dump into the new service before you switch traffic.
What the Kamal importer does not move:
- Secret values. Variables under
env.secretimport as empty placeholders. Set their real values in Temps (they're encrypted at rest). - Volume contents. Data in
volumesstays on your servers. Temps app containers have no persistent volumes, so move files to object storage such as Temps managed S3 before you cut over. asset_pathbridging. Kamal bridges fingerprinted assets between versions; Temps handles each deployment on its own.
Before you start
Two things to resolve before pasting the file in:
- Secret values don't transfer. Variables listed under
env.secretindeploy.ymlare names only — their actual values live in.kamal/secrets(or your secrets manager), which the file never contains. They import as empty placeholders; fill in the real values in the Temps project after the import. - Resolve ERB templating first. If
deploy.ymluses ERB (<%= %>) for interpolated values, runkamal configand paste its rendered output instead of the raw template — Temps parses YAML, not ERB.
Step 1: Discover
Discover the service described in deploy.yml
- 1
In the Temps dashboard, go to Projects, then click Import.
- 2
Select Kamal as the source.
- 3
Paste the contents of config/deploy.yml (run kamal config first if it uses ERB).
- 4
Click Discover Workloads.
Step 2: Review the plan
Temps shows the plan it will execute: the project name, the image it will pull, the roles it will create as deployments, the proxy.host domain, the environment variables it found under env.clear (secret variables show as empty placeholders you'll fill in after import), any accessory it will create as a managed service, and the unsupported items listed above. Linking the Git repository is optional; without it the plan shows the project as image-based (Type: docker).
Step 3: Execute the import
Run the import end to end
- 1
Review the plan and click Execute Import.
- 2
Fill in the real values for any secret environment variable before the deployment needs them.
- 3
Temps creates the project and its services, pulls the discovered image, and starts the container.
- 4
Wait for the deployment to reach a healthy state — Temps verifies the app actually answers before reporting the import complete.
Your Kamal deployment keeps running the whole time — the import only reads the config file. Verify the imported app on its Temps-provided address before touching DNS.
After the import
Once you've confirmed the imported app behaves correctly, point DNS for the proxy.host domain at the Temps server. Temps issues the certificate once the record resolves, replacing kamal-proxy's Let's Encrypt handling. To add another domain, use the dashboard or bunx @temps-sdk/cli custom-domains create --project-id <id> -d app.example.com -y, as shown in moving the production domain. Keep the Kamal deployment running until you've verified normal traffic on Temps.
For the general import flow that applies across every supported platform, see Import an Existing Platform.