Supported Frameworks, Languages & Build Methods

Temps deploys Next.js, Vite, React, Node.js, Python, Go, Rust, Java, .NET, PHP, Ruby and anything with a Dockerfile. It auto-detects Next.js, Vite, Rsbuild, Docusaurus, Rust, Go, Python, Java, a Dockerfile or a Compose file from your repository; for everything else (Create React App, Express, NestJS, Astro, Nuxt, Laravel, Rails…) you choose a preset once and Temps builds it, usually with Autopack, its built-in builder. You can also deploy a pre-built Docker image or a static bundle.

Build methods

Temps offers four ways to get your application running:

For details on each method, see Docker Containers. The deployment pipeline explains what happens after the build.

How framework detection works

Temps uses two mechanisms, and it helps to know which one you're relying on.

1. Preset detection (repository files). When you connect a repository, Temps scans each directory for known filenames and reports every preset that matches, so you can pick when more than one applies — a repo with both a Dockerfile and a next.config.ts offers you both. Matches are ordered by priority:

1. Docker Compose — a recognised compose file (docker-compose.yml, compose.yaml, …)
2. Dockerfile
3. Framework config files — docusaurus.config.js/.ts, next.config.js/.mjs/.ts, vite.config.js/.ts, rsbuild.config.ts
4. Language manifests — Cargo.toml, go.mod, requirements.txt/pyproject.toml/setup.py/Pipfile, pom.xml/build.gradle/build.gradle.kts
5. nixpacks.toml — offers the Autopack (auto-detect) preset
6. index.html — only when nothing above matched, offers the static preset (nixpacks-static)

A package.json, composer.json, Gemfile, mix.exs or .csproj on its own isn't a detection signal. If nothing matches, the build fails with Could not auto-detect project type from files… Please specify a preset explicitly — there is no silent fallback. You then pick a preset yourself. The selectable set is:

nextjs, vite, react-app, rsbuild, docusaurus, rust, go, python, java, docker-compose, dockerfile, custom, autopack, and nixpacks plus its per-language variants nixpacks-node, nixpacks-python, nixpacks-rust, nixpacks-go, nixpacks-java, nixpacks-php, nixpacks-ruby, nixpacks-deno, nixpacks-elixir, nixpacks-csharp, nixpacks-dart and nixpacks-static.

There is no dedicated, selectable preset for Astro, Nuxt, Remix, NestJS, Express, SvelteKit, Angular, Rails or Laravel. Those frameworks deploy through a language preset — usually nixpacks-node, nixpacks-php or nixpacks-ruby — and Autopack derives the install, build and start commands from your project files. If it picks the wrong start command, set one with a web: line in a Procfile (or [start] cmd in nixpacks.toml).

2. Node framework detection (package.json dependencies). Within an Autopack (Node.js) build, Autopack reads your dependencies to recognise the framework, checking next, nuxt, @remix-run/node or @remix-run/serve, @sveltejs/kit, astro, @nestjs/core, @angular/core, react-scripts and vite in that order. It starts the app with the first of: a Procfile web: line, your start script, the main file in package.json, or a common entry file such as server.js or index.js. Create React App, Vite and Astro builds without a server adapter or a start script are served as static sites from inside your app's container instead.

Deploy guides

Step-by-step tutorials for each framework: Next.js, React, Vue.js, Angular, Astro, SvelteKit, Remix, Docusaurus, Node.js, Django, FastAPI, Laravel, Ruby on Rails, Go, Rust, Java, .NET, Elixir.

Framework presets

Presets are framework-specific build configurations. When Temps detects a framework from repository files, it selects the matching preset to generate an optimised Dockerfile. You can also select a preset manually when creating a project.

JavaScript and TypeScript

Only four JavaScript presets are detected from repository files. Everything else in this table has no file signal — a bare package.json does not select a preset on its own — so choose the preset shown.

Python

Any of requirements.txt, pyproject.toml, setup.py or Pipfile selects the single python preset (default port 8000). There is no separate Django, Flask or FastAPI preset — all three deploy through python, which builds with Autopack and picks the start command from your code:

Gunicorn and Uvicorn are added to the build when your dependencies don't include them. If the generated start command isn't the one you want, set it with a web: line in a Procfile. The Python version comes from .python-version, runtime.txt or requires-python in pyproject.toml, and defaults to 3.12.

Go, Rust and Java

If your app listens on a different port, set the project's port in its settings.

PHP

With nixpacks-php selected, Autopack recognises composer.json or index.php and serves the app with FrankenPHP (document root public/ when present). The PHP version comes from require.php in composer.json and defaults to 8.3; extensions come from the ext-* entries. Laravel deploys through the same preset, with its Vite assets built; there is no separate Laravel preset.

Ruby

With nixpacks-ruby selected, Autopack detects the Gemfile. Rails apps deploy through the same preset and start with bundle exec rails server -b 0.0.0.0 -p ${PORT:-3000}; other Rack apps, such as Sinatra, start from config.ru with bundle exec rackup. The Ruby version comes from .ruby-version or the ruby line in your Gemfile, and defaults to 3.3.

Elixir and .NET

Neither is auto-detected. Choose Autopack (Elixir) (nixpacks-elixir) to build a mix release — see Deploy Elixir — or Autopack (C# / .NET) (nixpacks-csharp) to build with dotnet publish — see Deploy .NET.

Special presets

Docker Compose

Temps deploys docker-compose.yml / compose.yaml stacks directly via the docker-compose preset — this is a first-class deployment method, not a workaround.

Select the Docker Compose preset when creating a project and point it at a repository containing a compose file (or paste one inline for a manual project). On deploy, Temps:

• Reads the compose file from your repo (or the inline content) and merges in your project's environment variables
• Builds any services with a build: directive, then runs docker compose up in an isolated project namespace per environment
• Discovers the resulting containers and tracks all of them against the deployment — one project can run multiple containers, not just one
• Exposes each service that publishes a port through the Temps proxy; internal-only services (e.g. a database with no published port) stay off the public network
• Applies a Temps-only override you set in the project's Docker Compose settings, so you don't have to edit the compose file in your repo (docker-compose.temps-override.yml and the other docker-compose.temps-*.yml names are reserved for files Temps generates)

For the full walkthrough (environment variables, ports and domains, volumes, the security policy and redeploys), see Deploy a Docker Compose stack. For single-container deploys, see Docker Containers.

Autopack languages

For languages without a first-class preset, Temps uses Autopack, its built-in builder, to detect, build, and package your application. Autopack supports 24 ecosystems:

Node.js, Python, Rust, Go, Java, PHP, Ruby, Deno, Elixir, C# / .NET, Dart and static files each have a preset you can select (nixpacks-node, nixpacks-python, and so on, shown as Autopack (Node.js) and so on). The other languages build through the Autopack (auto-detect) preset (autopack).

Autopack reads optional configuration from your repository root: autopack.json, then railpack.json, then nixpacks.toml.

Package managers

Temps detects your Node.js package manager from the lock file:

Under Autopack (Node.js), the packageManager field in package.json also counts, and dependencies install with the lock file enforced (for example npm ci). The Node.js version comes from .nvmrc, .node-version or engines.node in package.json, and defaults to 24.

Monorepo tools

Temps detects and supports these monorepo build tools:

All monorepo tools work with all four package managers (npm, Yarn, pnpm, Bun). Set the App Directory in project settings to the subdirectory containing each app — see Your First Deployment. Full walkthrough: Deploy a Turborepo monorepo to your own server.

Build configuration

Every preset supports these optional overrides, configurable from the project settings:

Health checks, cron jobs and alerts are configured in a .temps.yaml file in your repository.

Docker

If a Dockerfile is present in the repository root (or the configured app directory), Temps can use it directly instead of generating one.

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Temps routes traffic to the environment or project port if you set one, otherwise to the port in the image's EXPOSE directive, otherwise to 3000.

When using a custom Dockerfile or the generated Dockerfile, Temps supports:

• Multi-stage builds — all generated Dockerfiles use separate build and production stages
• BuildKit — enabled by default; supports --mount=type=cache for dependency caching
• Build arguments — environment variables are injected as ARG directives and passed via --build-arg
• Custom base images — any base image works in your custom Dockerfile
• Platform targeting — linux/amd64 and linux/arm64

Static sites

A Git repository with an index.html and no other detected build is offered the static preset (nixpacks-static), which deploys the files as they are, with no build step. You can also upload a pre-built bundle (see Build methods).

The vite, react-app, rsbuild and docusaurus presets take a different deployment path from server apps: Temps builds a container image, extracts the build output from it, and the proxy serves the files directly. No container is left running for any of them. Single-page apps get an index.html fallback; Netlify-style _redirects files are not supported.

Container runtime

Every deployed container runs with these defaults:

Only limits are applied to the container; the CPU and memory requests stored on a project are not reserved. See Resources for the full settings model and Scaling for replicas.

Security is enforced at the container level:

• All Linux capabilities are dropped
• no-new-privileges is set
• PID limit of 512 processes
• Containers bind to localhost — external access goes through the Temps proxy with automatic TLS

Override detection

If Temps detects the wrong framework, change the preset under Project → Settings → Build & deploy → Build → Framework, or pass --preset to up.

To change the install command, build command or output directory, add a build section to .temps.yaml in your repository root:

build:
  install_command: npm ci
  build_command: npm run build:production
  output_dir: dist

For Autopack presets, set the start command with a Procfile web: line or your package's start script. For monorepos, set the App Directory in project settings.

What is not supported

Outside of the Docker Compose preset above, every other Temps project deploys as a single container (or static file bundle) per environment. The following are explicitly not supported:

Managed Services vs. Docker Compose

Both let a project use a database, cache, or queue — pick based on how much control you need:

See Deploy with a Database for the Managed Services path, or the Docker Compose section above to deploy a compose stack directly.