Deploy Vue.js on Temps
Push to your branch and Temps takes it from there — static Vue apps built with Vite are served from the dist/ directory with long-lived cache headers, while Nuxt SSR apps run as Node.js containers with automatic HTTPS. No Dockerfile needed.
This guide describes how the nightly release channel builds your app, using the Autopack builder. Beta (v0.1.0-beta.56) also builds with Autopack, but some details below may differ. Earlier releases and the stable channel build with Nixpacks and behave differently. To run nightly, see Release channels.
For an overview of self-hosting Vue, including costs, see Deploy Vue to your own server. Every framework and the preset it needs is listed under Supported platforms.
Quickstart
From your project root, deploy with your preferred package manager:
npx @temps-sdk/cli up
Temps detects a Vite project from its vite.config.js or vite.config.ts, runs its build script, and serves the output. Static apps are live in a few minutes. Nuxt isn't detected; see Nuxt SSR below.
Static Vue (Vite)
With the Vite preset, Temps installs dependencies with the package manager your lockfile points to, runs its build script (for example npm run build), and serves the dist/ output from the Temps proxy, with long-lived cache headers for hashed assets. No container runs for a static app.
Vue CLI projects aren't detected. Choose the Vite preset for them as well, under Project → Settings → Build & deploy → Build → Framework: it runs your build script and serves dist/, which is where Vue CLI writes its output.
| Feature | How Temps handles it |
|---|---|
| Build | Your package manager's build script |
| Output | Serves dist/, or the build.output_dir set in .temps.yaml |
| SPA routing | 404 → index.html fallback |
| Cache | Hashed assets get 1-year cache headers |
| HTTPS | Let's Encrypt, auto-renewed |
Nuxt SSR
Nuxt applications using server-side rendering run as Node.js containers. Choose the Autopack (Node.js) preset (nixpacks-node), with up --preset nixpacks-node or under Project → Settings → Build & deploy → Build → Framework.
Temps runs your build script (nuxt build), but a new Nuxt project has no start script, so tell Temps how to start the server. Add a Procfile to the repository root:
Procfile
web: node .output/server/index.mjs
A start script with the same command works too.
| Feature | How Temps handles it |
|---|---|
| Build | Your build script (nuxt build) |
| Start | The Procfile web: line or your start script |
| Port | The Nuxt server reads the PORT Temps sets |
| Runtime config | NUXT_ env vars supported |
The Nuxt server also reads the HOST variable, which Temps sets to 0.0.0.0.
Platform behavior
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) 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: /healthOnly path is used. Other health fields (status, interval, timeout, retries) are accepted but currently have no effect.
/health endpoint that returns a simple 200. This avoids issues where / requires authentication or returns a redirect.Environment variables
# Runtime config (Nuxt) npx @temps-sdk/cli environments vars set NUXT_PUBLIC_API_URL "https://api.example.com" -e production # Build-time (Vite) npx @temps-sdk/cli environments vars set VITE_API_URL "https://api.example.com" -e production
SPA routing
Static Vue apps (Vite) use client-side routing, handled automatically by the proxy.
Single-page applications use client-side routing — paths like /about or /dashboard/settings do not correspond to files on disk. The Temps proxy handles this automatically.
When a request arrives for a path that:
- Has no file extension (e.g.
/about, not/about.css) - Does not match any file on disk
…the proxy serves index.html instead, and your client-side router (React Router, Vue Router, etc.) takes over. This works out of the box — you do not need _redirects, vercel.json, or any rewrite rules.
Caching
The Temps proxy sends ETags with static files, so a browser that already has an unchanged file gets 304 Not Modified instead of downloading it again. The proxy doesn't compress static files.
Cache-Control headers are set based on the file path:
| Pattern | Cache-Control | Use case |
|---|---|---|
/assets/*, /static/*, /_next/static/*, .chunk.*, .hash.* | public, max-age=31536000, immutable | Hashed assets that never change |
| Everything else | public, max-age=0, must-revalidate | HTML files and non-hashed resources |
Your hashed JS and CSS bundles are cached for a year, while index.html is always revalidated so new deployments are picked up immediately.
The React and Angular guides use the same static setup.