Projects
A project is the top-level organizational unit in Temps — it represents one deployable application: a web app, an API, a static site, or a documentation site. Everything in Temps (deployments, environments, domains, analytics, error tracking, environment variables) belongs to a project.
What is a project
A project is a mapping between a source (a Git repository, a Docker image, or a static file bundle) and a running application on your server. When you create a project, you tell Temps where the code lives and how to build it. Temps handles the rest: cloning, building, deploying, routing, SSL, and monitoring.
Each project gets:
- A slug derived from its name (e.g.
my-app), used in URLs and container names - A default environment (production), with optional preview environments per branch
- An auto-assigned subdomain under your Temps base domain (e.g.
my-app.yourdomain.com, ormy-app.203-0-113-1.sslip.ioif you installed without your own domain) - Its own deployment history, analytics, error tracking, and logs
What a project contains
| Component | Description |
|---|---|
| Environments | At least one (production). Additional environments for staging, preview branches, etc. Each has its own containers, domains, and deployment config (resources). |
| Deployments | The history of every build and deploy. Each deployment is linked to a Git commit (or an image/bundle). |
| Environment Variables | Key-value pairs injected into containers at deploy time. Each is assigned to one or more environments. |
| Domains | Custom domains with automatic Let's Encrypt certificates, assigned per environment. |
| Linked Services | Managed databases and storage (PostgreSQL, Redis, MongoDB, S3) connected to the project. They are not created automatically: you create the service, then link it, and Temps injects its connection variables (for example POSTGRES_URL for PostgreSQL, REDIS_URL for Redis). |
| Analytics | Page views, visitors, custom events, funnels, and session replays (replay is off until you enable it). |
| Error Tracking | Captured errors with stack traces, grouped by type. Each project has its own Sentry-compatible DSN. |
| Monitors | Uptime checks that verify the application is healthy. |
| Webhooks | Outbound HTTP notifications for deployment events. |
Project sources
A project's source determines where the code comes from and how it is built.
| Source type | How it works |
|---|---|
| Git repository | Temps clones the repo, detects the framework, builds a Docker image, and deploys it. Pushes to the tracked branch trigger automatic deploys. |
| Docker image | You provide a registry image (or upload a tarball). Temps pulls and deploys it without building. |
| Static files | You upload a zip or tar.gz of pre-built static files. Temps serves them directly. |
| Template | Temps forks a built-in starter template to your Git provider and deploys it. |
Git-based and template projects require a linked Git provider — see Connect a Git Provider to set up GitHub, GitLab, Bitbucket, Gitea, or another git server first.
The source type is set when you create the project. Git-based projects additionally have:
- A main branch (usually
mainormaster) that maps to the production environment - A framework preset (auto-detected for Next.js, Vite, Python, Go, Rust, Java, a Dockerfile and more; frameworks such as Express or Astro need the Node preset chosen manually — see Supported platforms)
- Optional build command and app directory overrides
How projects relate to other concepts
In words: a project has environments (production, staging and per-branch previews), and each environment keeps its own deployment history, with one current deployment serving traffic and its own custom domains. Environment variables, linked services such as PostgreSQL and Redis, analytics and error tracking, and monitors belong to the project.
- Project → Environments: A project has one or more environments. The production environment is created automatically. Preview environments are created per branch when enabled.
- Environment → Deployments: Each environment has its own deployment history. The "current" deployment is the one serving traffic.
- Project → Services: Managed services are created separately and then linked at the project level (Set up managed services). Each environment gets its own isolated database/cache within the shared service.
- Project → Environment Variables: Variables are defined at the project level and scoped to specific environments.
Naming and subdomains
The project name determines the default subdomain:
| Project name | Slug | Default URL |
|---|---|---|
| My App | my-app | my-app.yourdomain.com |
| API Service | api-service | api-service.yourdomain.com |
The slug is generated from the name: lowercased, spaces and special characters replaced with hyphens. It is used in:
- The default subdomain
- Docker container names (e.g.
my-app-production) - Per-project database names (e.g.
my_app_production) - File paths for static deployments
You can add custom domains to override the default subdomain. See Add a Custom Domain.
Project settings
Key settings available on each project:
- Name
Name- Description
Display name. Changing the name does not change the slug or existing URLs.
- Name
Branch- Description
The Git branch that maps to the production environment. Default:
main.
- Name
Framework Preset- Description
The detected or manually set framework. Affects how Temps builds the project.
- Name
Build Command- Description
Override the auto-detected build command (e.g.
npm run build).
- Name
App Directory- Description
For monorepos, the subdirectory containing the application.
- Name
Preview Environments- Description
Toggle automatic preview environments for non-main branches.
- Name
Deployment Config- Description
Default CPU, memory, replicas, and exposed port for new environments.
When to create a new project
Create a new project when:
- You have a separate deployable application (different repo, different build process)
- You want independent deployment history and analytics
- The application serves a different domain
- You want separate error tracking and monitoring
Use environments within the same project when:
- You need staging/preview versions of the same application
- You want to test the same codebase with different configuration
- You need branch-based previews for code review
One project per repo is the most common pattern. For monorepos with multiple deployable apps, create a separate project per app and set the App Directory to the relevant subdirectory.
Grouping Services under a Project
In this section, a Project is a group of Services; elsewhere on this page, "project" still means a single deployable app, which the experimental feature calls a Service.
When several Services ship together, such as a frontend, its API and a worker in one monorepo, a Project can hold them under one parent so they share a repository, environment variables and path routes. Each Service keeps its own builds, environments, domains and deployments, and a project that is in no Project behaves exactly as described above.
This is experimental and in nightly builds only. See Projects and Services for what it does and what is still undecided.