Deploy SvelteKit on Your Own Server
Push to your branch and Temps takes it from there — SvelteKit applications with server-side rendering, API endpoints, and form actions are built with the Node adapter and live in about 2 minutes. No config files needed. No downtime.
Quickstart
From your project root, deploy with your preferred package manager:
npx @temps-sdk/cli up
SvelteKit needs 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.
SvelteKit projects have a vite.config.js or vite.config.ts, so Temps detects them as the static Vite preset. That preset only serves files from dist/ and can't run the SvelteKit server, so switch the project to Autopack (Node.js).
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.
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
| Feature | How Temps handles it |
|---|---|
| Build | Your build script (for example npm run build) |
| Start | Your start script, or node build/index.js if there isn't one |
| HTTPS | Let's Encrypt, auto-renewed |
| Port | PORT env var injected, defaults to 3000 |
| API endpoints | Fully supported via Node adapter |
| Form actions | Fully supported |
| Static prerendering | Prerendered pages are served by the Node server |
Environment variables
npx @temps-sdk/cli environments vars set DATABASE_URL "postgres://..." -e production npx @temps-sdk/cli environments vars set SECRET "your-secret" -e production
Public variables use the PUBLIC_ prefix in SvelteKit.
Platform behavior
These rules apply to every app deployed on Temps, regardless of framework.
The one requirement: your app must listen on the port in the PORT environment variable and bind to 0.0.0.0 — not localhost or 127.0.0.1. Temps runs your app in a container and routes traffic from the host, so an app bound to localhost only accepts connections from inside the container and will fail its health check.
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) - Success: 2 consecutive responses with a 2xx or 3xx status code
- Timeout: 300 seconds (5 minutes) for the app to become healthy
- Retry interval: every 5 seconds
Connection errors while the app is still starting are retried without penalty. If the app returns 4xx or 5xx errors for 60 consecutive seconds, the deployment fails. Customize the check by adding a .temps.yaml to your repository root:
health:
path: /health
status: 200
interval: 30
timeout: 5
retries: 3/health endpoint that returns a simple 200. This avoids issues where / requires authentication or returns a redirect.Auto-injected environment variables
Temps injects these variables into every deployment automatically:
| Variable | Value | Description |
|---|---|---|
PORT | Resolved port | The port your app must listen on |
HOST | 0.0.0.0 | Bind address |
SENTRY_DSN | Auto-generated | Error tracking endpoint |
TEMPS_API_URL | Your Temps URL | Platform API endpoint |
TEMPS_API_TOKEN | Deployment token | Authentication for Temps SDKs |
OTEL_EXPORTER_OTLP_ENDPOINT | Your Temps OTLP URL | OpenTelemetry trace collection |
OTEL_SERVICE_NAME | Project name | Service identifier for traces |
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.