Projects
Organize your codebases, hosting platforms, and environments under a single workspace in Devpilot.
A project in Devpilot is the top-level container that groups together one or more apps (your actual codebases) along with the platforms and environments those apps use. Every deployment, domain, environment variable, and team member lives inside a project.
The project hierarchy
Devpilot uses a simple three-level hierarchy that mirrors how real product teams already think about their work.
Project
A workspace such as 'Marketing Site', 'Customer Portal', or 'Mobile Backend'. Holds apps, team members, and shared settings.
App
A single codebase or service inside a project. Each app has its own framework, language, repository, and platform configuration.
Environment
A stage such as production, staging, or preview. Environments carry their own variables, domains, and deploy targets.
What a project contains
Every project you create gives you a central place to manage:
- Apps — codebases connected to a source provider (GitHub, GitLab, or Bitbucket).
- Platform configurations — the hosting targets each app deploys to, such as Vercel, Netlify, Railway, Render, Fly.io, Cloudflare Pages, Heroku, DigitalOcean App Platform, or AWS ECS/Fargate.
- Custom domains — one or more domains attached to an app, with SSL status tracked by Devpilot.
- Environment variables — secrets and configuration detected from your repositories, deployments, and platform imports.
- Team members — collaborators invited to the project with per-app roles.
Project statuses
A project in Devpilot is always in one of three states.
Active
The project is in regular use. Apps can build, deploy, and receive environment updates.
Paused
Deployments and scheduled scans are temporarily halted, but all data is preserved.
Archived
Read-only snapshot. Useful for wound-down products where history should still be accessible.
Archiving a project does not delete its apps, domains, or environment variables. You can restore an archived project to Active at any time.
Typical project layouts
Different teams organize Devpilot differently. Here are three patterns that work well.
One project per product, with separate apps for the web frontend, API, and any background workers. Most SaaS teams start here.
One project for the monorepo, with an app for each deployable package (web, admin, docs site, API, workers). Each app can point at a different subdirectory in the same repository.
One project per client, each containing the apps delivered to that client. Team members can be invited per project so access stays scoped.