Configuration: environment variables, domains and TLS
Webhooks
Partiri supports automatic deployments triggered by Git push events. When you enable auto-deploy on a service, a webhook URL is generated that you can add to your repository settings. We support webhooks from GitHub, GitLab, Bitbucket, and Codeberg. Each push to the configured branch will trigger a new deployment automatically. Webhook secrets are generated for signature validation to ensure only legitimate pushes trigger builds.
Deploy hooks
Deploy hooks are unique URLs that trigger a new deployment when called with an HTTP POST request. They are useful for CI/CD pipelines that are not connected via Git push webhooks — for example, triggering a deploy after a custom build step in your pipeline, or deploying from a system outside your Git provider. To use a deploy hook: open the service settings, find the deploy hook URL, and make a POST request to that URL from your CI system. No request body or authentication header is required — the URL itself acts as the secret. You can regenerate the deploy hook URL at any time from the service settings to invalidate the previous one. Deploy hooks trigger a deployment of the current branch and configuration, the same as pressing the Deploy button in the dashboard.
Environment variables
Each service can have its own set of environment variables that are injected at runtime. Use them for configuration values, secrets references, API endpoints, and feature flags. You can add, edit, or remove environment variables from the service settings page. Changes take effect on the next deployment.
Health checks
You can configure a health check path for your service (for example, /health). The platform will periodically send HTTP requests to this endpoint to verify that your service is running correctly. If the health check fails, the platform will automatically restart the service. The endpoint should return a 200 status code when the service is healthy.
Credentials
To deploy from private Git repositories or private container registries, you need to configure credentials. Credentials are managed at the workspace level and can be reused across services. For Git repositories, you can use a personal access token. For container registries, provide your registry username and password or token. Supported Git providers are GitHub, GitLab, Bitbucket, and Codeberg. Supported registry providers are GitHub Container Registry, GitLab Container Registry, Docker Hub, Google Artifact Registry, and AWS ECR.
Monorepo support
If your repository contains multiple services in separate subdirectories, you can configure each Partiri service to build and deploy from a specific path within the repository. Set the Root path field in your service configuration to the subdirectory path (for example, apps/api or packages/backend). The platform will use that directory as the working directory when running your build and run commands. This works for both Git-based and Dockerfile-based deployments. You can have multiple Partiri services pointing to the same repository with different root paths, each deploying independently. When auto-deploy is enabled, a push to the configured branch will trigger a deployment for all services sharing that repository.
Persistent storage
Attach a persistent disk to a service from the Infrastructure section of its settings. Choose a size between 1 GB and 10 GB and an absolute mount path (for example /app/data) where the volume is mounted inside the container. The disk is provisioned and attached on the next deploy. When you remove a disk you can either detach it — keeping the data to reattach later — or delete it, which destroys the data. Persistent storage is not available for static sites or cron jobs and is incompatible with replica regions. See the Persistent Storage section for the full lifecycle and constraints.