Deployments with Git, Docker and the CLI
How it works
Every deployment starts the same way: you connect a source, either a Git repository or a container registry. Choose a location and pod size, and deploy. We pull your code, build it (if needed), and get it running. Each deployment is tracked, so you can see whether it succeeded or failed and roll things forward with confidence. No guessing, no surprises. All deployments run on infrastructure hosted within Europe.
Runtimes
We currently support the following runtimes: Node.js, Python, Go, Rust, Ruby, Elixir, PHP, JVM (Java/Kotlin), .NET, C++, and Static Sites.
Git providers
We accept private and public repositories from these providers: GitHub, GitLab, Bitbucket, and Codeberg.
Registry providers
If you prefer deploying from a container image, we accept private and public images from these registries: GitHub Container Registry, GitLab Container Registry, Docker Hub, Google Artifact Registry, and AWS ECR.
Scaling & pod sizes
Services run on pods. You select a pod size when creating a service, which determines the CPU and memory available to your container. Smaller pods are suitable for background workers, lightweight APIs, and static sites. Larger pods are appropriate for compute-intensive workloads, large language model inference, or services that hold state in memory. You can change the pod size at any time from the service settings page. The change takes effect on the next deployment. All pod sizes include a fixed allocation of CPU and memory — there is no bursting or shared-CPU throttling.
Zero-downtime deployments
By default, deployments are rolling updates. When you trigger a deployment, the new version of your service is started alongside the old one. The platform waits for the new pod to pass its health check before directing traffic to it and stopping the previous pod. This means your service stays available throughout the deployment with no interruption for your users. If the new version fails to start or fails its health check within the deployment timeout window, the deployment is marked as failed. The old version continues running, so your service remains available while you investigate the issue. To minimize the risk of failed deployments: set a health check path on your service, keep your startup time short, and test your build locally before pushing.
Rollbacks
Every deployment is tracked in your service's job history. Each job records the Git commit SHA or container image tag that was deployed. If a deployment introduces a regression or fails in production, you can return to a previous version by opening the service, navigating to the Jobs tab, and redeploying a previous successful job. A rollback creates a new deployment job using the same source reference as the selected job — it follows the same build and health check process as any other deployment. You can also trigger a deployment from the CLI using partiri service deploy, which will redeploy the latest configuration. If you need to redeploy a specific commit, push a revert commit or update your branch to the desired commit SHA and deploy from there.
Multi-region replicas
Web services, private services, static sites, and workers can run simultaneously in multiple regions. After selecting a primary region, add as many replica regions as you need from the service settings under Infrastructure. Each replica runs a full independent copy of your service in its chosen region. Each region can only appear once: you cannot use the same region for both the primary and a replica, or for two replicas. Replicas are not available for Cron Jobs, which run in a single region, and cannot be combined with Persistent Storage (a volume binds to a single region — remove the disk first to enable replicas).
Persistent storage
By default a service's filesystem is ephemeral — anything written inside the container is lost on restart or redeploy. Attach a persistent disk and that data survives across deploys, restarts, and pod rescheduling: the volume is mounted on the next deploy and re-mounted on every subsequent one, so stateful workloads such as file uploads, SQLite databases, or caches keep their data through your release cycle. Persistent disks are available for web services and private services, but not for static sites or cron jobs, and they are incompatible with replica regions. See the Persistent Storage section for sizing, mount paths, and the volume lifecycle.