Migrate from Portainer to Temps

To move from Portainer to Temps, sign the Temps import wizard in to Portainer with a username and password, pick a Compose stack or standalone container, review the plan, and execute it. Temps reads the containers through Portainer's API, recreates them as a Temps project that runs the same image with the same environment variables, creates managed services for database containers, and copies their data when the database publishes a host port. Volume contents are not copied, so plan for those separately.

What Temps discovers from Portainer

Portainer manages Docker environments rather than apps, so the importer treats a Compose stack (containers sharing a com.docker.compose.project label) as the project boundary:

The stack's containers. The one you pick becomes the project; the others become additional deployments. A standalone container that belongs to no stack imports as a single-container project.
Environment variables, read from each container through Portainer's Docker API.
Database containers (known database images) in the stack, which become Temps-managed services. Connection details are rebuilt from the container's environment variables and published port.
Published ports, which tell Temps which port the app listens on.

Portainer workloads are containers, not Git repositories, so the imported project runs the discovered image. There's no build step.

Will my data come across?

PostgreSQL, MySQL/MariaDB and MongoDB data is copied by a one-off dump/restore during the import only if the database container publishes a host port, because that is the only way Temps can reach it from outside the Portainer host. Without one, the plan marks the data as not migrated and tells you to either publish the port in Portainer before importing or dump the database on the host (docker exec) and restore it into the new Temps service.

What the Portainer importer does not move:

Volume contents. Docker volume data is never copied; only databases have a dump/restore path. Copy non-database volume data yourself. Temps app containers have no persistent volumes, so put uploads and other files in object storage such as Temps managed S3, or deploy the stack as a Docker Compose project with named volumes.
Domains. Portainer has no domain concept, so there is nothing to import as a custom domain. Add your domains in Temps after the import.
Swarm-mode scaling. Swarm services (replicas, placement constraints) collapse to a single container per Temps environment. Set replicas in Temps afterwards if you need them; see scaling.
Redis data. A Redis service is created empty, which is fine for a cache. If you keep data in Redis that you need, copy it yourself.

Before you start

Temps' Portainer importer signs in with a Portainer username and password and exchanges them for a short-lived session token. It doesn't use Portainer access tokens (the X-API-Key tokens from My account → Access tokens). The dashboard signs in as admin: paste the admin password into the field labelled API token. To sign in as a different user, use the CLI's --username flag. Credentials are sent per request and never stored.

You'll also need your Portainer instance's URL (e.g. https://your-portainer-host:9443).

Portainer ships a self-signed TLS certificate by default. If discovery fails against your instance's :9443 port, check Skip TLS certificate verification in the credentials step — it's only ever sent when you explicitly enable it.

The Temps import wizard's Connect to Portainer credentials form, showing the Instance URL, API token, and Skip TLS certificate verification checkbox

Step 1: Connect and discover

Discover what's running on Portainer

Three ways to do this

1
In the Temps dashboard, go to Projects, then click Import.
2
Select Portainer as the source.
3
Enter the instance URL and the admin password. If your instance uses the default self-signed certificate, check Skip TLS certificate verification.
4
Click Discover Workloads.

Temps queries the Portainer API directly — nothing is created on this step.

Step 2: Review the plan

Pick the container or stack to import and Temps shows the plan it will execute: the project name, the image it will pull, every environment variable it found (secrets masked), the databases it will create as managed services with what will happen to each one's data, and the warnings and unsupported items listed above. The repository step is optional; without a linked repository the plan shows the project as image-based (Type: docker).

Step 3: Execute the import

Run the import end to end

Three ways to do this

1
Review the plan and click Execute Import.
2
Temps creates the project and its services, pulls the discovered image, and starts the container.
3
Wait for the deployment to reach a healthy state — Temps verifies the app actually answers before reporting the import complete.

Your Portainer instance keeps running the whole time — the import only reads from it. Verify the imported app on its Temps-provided address before touching DNS.

After the import

Once you've confirmed the imported app behaves correctly, add your production domain and cut DNS over: bunx @temps-sdk/cli custom-domains create --project-id <id> -d app.example.com -y, or the dashboard steps in moving the production domain. Keep the Portainer stack 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.