Projects and Services
Forge uses projects to group services that belong to the same application stack. A project can contain source-built apps, Docker image services, background workers, static sites, and databases.
Projects
Section titled “Projects”Use a project as the operational boundary for a stack. It gives you one place to scan services, create resources, follow deployments, wire domains, manage variables, browse data, and configure backups.
Projects are also the boundary for database variable suggestions. When you add an app service, Forge can suggest variables that reference database services in the same project.
Domains And Email Ownership
Section titled “Domains And Email Ownership”Web services receive a generated Forge hostname when one is available. Attach a domain you own from that service’s Domains tab and publish the exact DNS records Forge displays.
Email domains and sender identities are created inside a project, so one project’s email credentials and sending records are not shared with another project. A service domain and an email identity can use the same registered domain only after completing their separate verification steps.
Source Services
Section titled “Source Services”Source services are connected to code. Forge can read from:
- GitHub repositories through the GitHub App connection.
- Manually entered uncredentialed GitHub HTTPS URLs such as
https://github.com/owner/repo.git.
Forge builds source services and runs the resulting deployment on the selected server.
Typical service work includes:
- Choosing the source repository and branch.
- Choosing the root directory for monorepos.
- Selecting
weborworkerruntime mode. - Setting the internal port for web services.
- Overriding install, build, or start commands when auto detection is not enough.
- Setting a static output directory when the build produces static files.
- Setting environment variables.
- Running manual deployments.
- Using push-triggered deployments.
- Watching build and runtime logs.
- Assigning generated or custom domains.
Docker Image Services
Section titled “Docker Image Services”Docker image services run a prebuilt container image. Use them when CI already publishes an image, when you want to run third-party software, or when the selected server is authorized to pull a private image.
Docker image services can be web or worker services. Web services need an internal container port. Worker services do not.
Database Services
Section titled “Database Services”Forge can create these database engines:
- PostgreSQL
- TimescaleDB
- MySQL
- Redis
- MongoDB
- ClickHouse
- Qdrant — vector database for AI embeddings and semantic search
- MinIO — S3-compatible object storage
Database panels give you operational access next to the apps that depend on them.
Depending on the engine, you can browse data, run SQL where applicable, import data, and configure backups.
Service Tabs
Section titled “Service Tabs”Services expose tabs based on their type:
- Overview for status and warnings.
- Deployments for manual deploys, queue state, build logs, aborts, and deployment history.
- Logs for runtime logs.
- Variables for environment variables.
- Domains for generated and custom hostnames.
- Data, SQL, and Backups for database services where supported.
- Settings for runtime and database settings.
Status and URLs
Section titled “Status and URLs”Forge tracks service status separately from deployment status. A service can be active while a newer deployment is queued or building.
Web and static services get a preferred URL. Database services can get public hostnames when database public access is enabled and the root domain is configured.
Runtime Shape
Section titled “Runtime Shape”Forge keeps deployments, persistent database storage, service routes, generated domains, variables, logs, backups, and maintenance close to the service they affect.