Deploy SvelteKit on Temps

Install @sveltejs/adapter-node, select the Autopack (Node.js) preset (nixpacks-node) and run up: Temps runs your build script and starts node build/index.js on $PORT, so server rendering, API endpoints and form actions run in a persistent Node.js process with HTTPS.

For an overview of self-hosting SvelteKit, including costs, see Deploy SvelteKit to your own server. Every framework and the preset it needs is listed under Supported platforms.

Quickstart

After adding the Node adapter, deploy from your project root with the Autopack (Node.js) preset (nixpacks-node), which runs your app as a Node.js server:

npx @temps-sdk/cli up --preset nixpacks-node

Or pick it under Project → Settings → Build & deploy → Build → Framework.

With Autopack (Node.js), Temps runs your build script and starts the app with your start script. If there's no start script, it runs node build/index.js, which is where the Node adapter writes the server. A web: line in a Procfile takes priority over both. The Node adapter's server reads the PORT and HOST variables that Temps sets. The Node.js version comes from .nvmrc, .node-version or engines.node in package.json, and defaults to 24.

Node adapter setup

SvelteKit requires the Node adapter for production deployments on Temps:

npm install -D @sveltejs/adapter-node

// svelte.config.js
import adapter from '@sveltejs/adapter-node';

export default {
  kit: {
    adapter: adapter()
  }
};

What Temps handles automatically

Environment variables

npx @temps-sdk/cli environments vars set SECRET "your-secret" -e production

Public variables use the PUBLIC_ prefix in SvelteKit. If you link a managed PostgreSQL database, Temps injects POSTGRES_URL (not DATABASE_URL); read it with $env/dynamic/private. See Deploy with a Database.

Platform behavior

These rules apply to every app deployed on Temps, regardless of framework.

Health checks

After your container starts, Temps sends HTTP GET requests to verify it is healthy before routing traffic to it.

• Path: / (the root of your application) by default
• Success: 2 consecutive responses with a 2xx, 3xx, 404 or 405 status code
• Timeout: 300 seconds (5 minutes) for the app to become healthy, fixed in v0.1.0-beta.56. If the app answers with error responses (other 4xx, or 5xx) for 60 seconds in a row, the deployment fails sooner. From the next release the timeout is configurable from 30 to 3600 seconds under Project → Settings → Build & deploy
• Retry interval: 2 seconds between successful checks, 5 seconds after an error response or a failed connection

Connection errors and other 4xx or 5xx responses are retried until the timeout; if the app hasn't passed by then, the deployment fails. The check runs once, at deploy time. To check a different path, add a .temps.yaml to your repository root:

health:
  path: /health

Only path is used. Other health fields (status, interval, timeout, retries) are accepted but currently have no effect.

Auto-injected environment variables

Temps injects these variables into every deployment automatically:

You do not need to configure these manually. They are available in process.env (Node.js), os.environ (Python), os.Getenv (Go), and the equivalent in other languages.

Deploying another server-rendered framework? The Remix and Next.js guides follow the same pattern.

Next Steps