Supported Languages, Frameworks & Build Methods

Everything Temps can build and deploy, at a glance. Temps supports 20+ languages via Nixpacks, first-class presets for popular frameworks, Dockerfile builds, pre-built Docker images, Docker Compose stacks, and static file deployments.

---

Build methods

Temps offers four ways to get your application running:

For details on each method, see Docker Containers and the per-framework deployment guides.

---

Framework presets

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

JavaScript / TypeScript

Python

Other languages

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 now 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
• Supports a docker-compose.temps-override.yml file for Temps-specific overrides without editing your original compose file

For details, see Docker Containers.

---

Nixpacks languages

For languages without a first-class preset, Temps uses Nixpacks to detect, build, and package your application. Nixpacks supports 20+ languages:

You can select a specific Nixpacks provider (e.g. nixpacks-python, nixpacks-ruby) when creating a project, or let Nixpacks auto-detect.

Nixpacks reads optional nixpacks.toml or .nixpacks.toml configuration files from your repository root for custom build configuration.

---

Package managers

Temps detects your Node.js package manager from the lock file and uses the appropriate commands:

---

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 Deploy a Project.

---

Preset detection priority

When auto-detecting from your project files, Temps checks in this order. The first match wins:

1. Dockerfile exists → Dockerfile preset
2. docusaurus.config.js / .ts → Docusaurus
3. next.config.js / .mjs / .ts → Next.js
4. vite.config.js / .ts → Vite
5. react-scripts in package.json → Create React App
6. rsbuild.config.ts → Rsbuild
7. Cargo.toml → Rust
8. go.mod → Go
9. requirements.txt, pyproject.toml, setup.py, Pipfile → Python
10. pom.xml, build.gradle, build.gradle.kts → Java
11. nixpacks.toml → Nixpacks (explicit)
12. No match → no preset selected (you must choose one manually)

---

Build configuration

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

Dockerfile features

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

---

Container runtime

Every deployed container runs with these defaults:

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

---

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.