Version v2.2.5 turns the platform into a place you can ship code, not just run servers. The headline is Git Push-to-Deploy: customers connect GitHub, GitLab, Bitbucket, or Gitea, point the platform at a repository, and every push is built and rolled out to their instance with zero downtime - no Dockerfile required, thanks to automatic build packs. Pull requests get their own disposable preview environments, complete with status comments posted back to the PR. Around the headline, the release adds live master updates so operators can upgrade the platform from a banner in the admin panel and watch it happen, unicast VXLAN so VPC networking works in datacenters without multicast, per-interface VPC speed controls, and a new bandwidth overage billing option that charges for extra traffic instead of cutting customers off.
-
[Feature] Git Push-to-Deploy - Deploy applications directly from a Git repository to an instance through the Docker Manager. Pick a repository and branch, choose how it builds, and the platform clones, builds, and runs it. From then on, every push to the branch deploys automatically.
-
[Feature] Four Git Providers - Connect GitHub through a guided GitHub App flow with repository and branch browsing built into the panel, or connect GitLab, Bitbucket, and Gitea. Private repositories are supported through access tokens or SSH deploy keys, including custom SSH ports and users for self-hosted servers.
-
[Feature] Automatic Builds with Build Packs - Applications build with Nixpacks or Railpack, which detect the language and framework and produce a container image with no Dockerfile in the repository. A plain Dockerfile and a static-site build pack are also available. Builds run inside an isolated helper container, so no build tooling is ever installed onto the instance itself.
-
[Feature] Zero-Downtime Rolling Deploys - A new deployment starts the new container, waits for it to come up healthy, switches traffic over, and only then removes the old one. Traffic is routed through a managed reverse proxy with automatic HTTPS certificates.
-
[Feature] Pull-Request Preview Environments - Every pull request can get its own live preview deployment on its own URL. The preview is updated on each new commit, the deployment status is posted back to the pull request as a comment, and the environment is torn down when the PR closes. A previews list in the panel shows what is running and allows manual teardown.
-
[Feature] Dedicated Build Hosts - Builds can be offloaded from the application instance to a separate build host. Each user gets their own deploy keypair, and the panel includes a guided onboarding flow with a connection test before the host is used.
-
[Feature] Deploy Controls and Logs - Webhook deploys are signature-verified, a deployment can be skipped by putting [skip ci] or [skip cd] in the commit message, and full build and deploy logs are available in the panel with credentials automatically redacted.
-
[Feature] Live Master Updates - When a new platform version is available, an update banner appears in the admin panel. One click starts the upgrade, and a live console streams the update progress in real time until it completes. The dashboard now also carries a version pill showing the running release.
-
[Feature] Unicast VXLAN for VPC Networking - Each hypervisor group can now run its VPC overlay in unicast mode instead of multicast. Unicast mode works in datacenters and on networks where multicast is not available, which removes the most common blocker to enabling VPC networking. Existing groups keep multicast by default.
-
[Feature] VPC Interface Speed Controls - Operators can set default inbound and outbound speed limits for VPC network interfaces per hypervisor group, and override them per instance plan. Customers see the effective limits on their instance’s network details.
-
[Feature] Bandwidth Overage Billing - Instance, managed database, load balancer, and VPN gateway plans gain a Charge Overage option. When a customer exhausts the plan’s bandwidth allowance, traffic keeps flowing and the extra usage is billed per gigabyte at the rate set on the plan, charged through the hourly billing cycle. The existing cut-off behavior remains available for plans that prefer it.
-
[Feature] Expanded Instance Charts - Instance monitoring gains disk I/O, disk usage, and network packet and error charts alongside the existing CPU, memory, and bandwidth graphs.
-
[Fix] Mail Transport Fallback - Outgoing mail no longer fails when the mail transport setting is left blank; the platform falls back to the configured driver.
Git Push-to-Deploy
The Docker Manager introduced in the beta releases let customers run containers from existing images. v2.2.5 closes the loop: customers can now deploy straight from source code, the way they would on a dedicated platform-as-a-service, on infrastructure you operate.
Connecting a Provider
Git providers are connected once, from a new Git Sources area in the customer panel. GitHub uses a guided app-creation flow: the panel walks the customer through creating and installing a GitHub App against their account or organization, and from then on the panel can browse their repositories and branches directly in deploy forms. GitLab, Bitbucket, and Gitea connect with an access token, and any provider - including self-hosted Git servers - can be reached over SSH with a per-application deploy key, custom port, and custom user. Source credentials are stored encrypted.
From Repository to Running Application
Creating an application is a short form: pick the source, repository, and branch, choose a build pack, and set any environment variables. Two automatic build packs are available - Nixpacks and Railpack - which inspect the repository, detect the language and framework, and build a container image without the repository needing a Dockerfile. Repositories that do have a Dockerfile can use it directly, and a static build pack serves prebuilt sites. Builds execute inside a dedicated helper container on the target machine, so compilers, package managers, and build tools never touch the instance’s own filesystem.
Once the application exists, deployments happen three ways: a Deploy Now button in the panel, an automatic deploy on every push to the configured branch via webhooks (signature-verified, with sensible rate limits), or a redeploy triggered from a pull-request update. Commits containing [skip ci] or [skip cd] are skipped. Every deployment’s build and run logs are kept and viewable in the panel, with tokens and credentials redacted automatically.
Zero-Downtime Rollouts
Deployments are rolling: the new container is started alongside the old one, health-checked, and switched into the routing layer before the previous version is removed. The routing layer is a managed reverse proxy with automatic HTTPS certificate issuance, so applications get a working TLS endpoint without manual certificate handling.
Preview Environments
For teams reviewing changes, pull requests can spin up preview environments. When a PR opens, the platform builds that branch and deploys it as a separate, disposable application with its own URL. New commits to the PR redeploy the preview, the deployment result is posted to the pull request as a status comment, and closing or merging the PR tears the preview down. Reopened PRs get their preview restored. The panel lists all live previews per application with a manual teardown control.
Build Hosts
Building on the application instance is the default and requires nothing extra. Customers who want faster or isolated builds can enable a dedicated build host: the panel generates a per-user keypair, shows the public key to install on the host, verifies the connection with a test button, and routes subsequent builds there.
Live Master Updates
Upgrading the master server previously meant a trip to the command line. In v2.2.5 the platform watches for new releases and shows an update banner in the admin panel when one is available. Starting the update opens a live console that streams every step of the upgrade - download, dependency refresh, migrations, service restarts - in real time over WebSocket, and reports clearly whether the update finished or failed. A version pill on the admin dashboard always shows the release currently running. The old System Updates page is retired in favor of this flow.
Networking: Unicast VXLAN and Interface Speeds
VPC networking has until now relied on multicast VXLAN between hypervisors, which many datacenters and most cloud underlays do not carry. Each hypervisor group can now be switched to unicast mode, where the master tracks which hypervisors participate in each VPC and distributes the peer list to the agents directly - no multicast required. Existing groups stay on multicast by default and behave exactly as before; new deployments on multicast-free networks can choose unicast and use the full VPC feature set.
VPC interfaces also gain proper speed controls. Operators set default inbound and outbound limits per hypervisor group, and can override them per instance plan, so a premium plan can carry faster private networking than an entry-level one. Previously VPC interfaces were attached without a speed limit.
Bandwidth Overage Billing
Plans have always had a bandwidth allowance with a hard consequence: exhaust it and traffic is restricted. v2.2.5 adds a gentler, revenue-positive alternative. Setting a plan’s bandwidth behavior to Charge Overage keeps the customer online when the allowance runs out and bills the excess per gigabyte at a rate configured on the plan. The charges run through the existing hourly Cloud Service billing cycle and are recorded incrementally, so usage is never double-billed even if a billing run is retried. The option is available on instance, managed database, load balancer, and VPN gateway plans, and the original cut-off behavior remains the default for plans that keep it.