Release Version v2.2.5

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, a new bandwidth overage billing option that charges for extra traffic instead of cutting customers off, and a platform-wide security hardening pass.

• [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] Self-Provisioning Bandwidth Window - Bandwidth usage for self-provisioning packs now resets on the pack's purchase anniversary instead of drifting, and enforcement that had silently stopped working is restored.
• [Fix] Static IP Billing Consistency - Hourly static IP charges are now applied atomically, so an interrupted billing run can no longer leave a credit deduction and its usage record out of step.
• [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.
• [Security] Tenant Isolation Hardening - Ownership checks were tightened across user-facing routes, request authorization, and real-time WebSocket channels, closing paths where one account could read or act on another account's resources, including a flaw that allowed database backups to be deleted across accounts.
• [Security] Master-Hypervisor Channel Hardening - Authentication between the master and hypervisor agents now uses constant-time token comparison, and TLS certificate verification for hypervisor connections can be enabled for deployments with proper certificates.
• [Security] Input Hardening - Mass-assignment guards and stricter validation were added across plan, billing, and Cloud Service endpoints, and sensitive billing and plan fields are no longer exposed in API responses. The AI Assistant gained server-side request guards and stricter validation of credit values.

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.

Security Hardening

This release carries a substantial security pass over the whole panel. Ownership scoping was tightened across user-facing routes and real-time channels so that resources are always resolved within the requesting account, closing several paths where a crafted request could touch another tenant's data - including one that allowed deleting another account's database backups. Request-level authorization and validation were hardened across plan, billing, and Cloud Service endpoints, mass-assignment protections were added on models, and sensitive billing and plan fields were removed from API responses. The master-to-hypervisor channel now compares authentication tokens in constant time, and operators with proper certificates on their hypervisors can enable TLS verification for that channel. The AI Assistant's outbound requests gained server-side guards, and the values it can write are validated more strictly.

Upgrade Notes

1. Refresh dependencies and rebuild the frontend bundles. The Git deploy pages, the live update console, and the new instance charts are part of the user and admin panels and need the bundles rebuilt before they appear.
2. Run database migrations to create the Git source, application, and preview tables, the build and bandwidth accounting columns, and the per-group VXLAN mode setting.
3. Restart queue workers so the deploy runner, preview lifecycle, and master-update jobs are picked up, and restart the WebSocket broadcaster so the new deployment and update events are registered.
4. Update hypervisor agents to the matching release before using the new networking features.
5. Git deploy setup: customers connect their own Git providers, so no operator-side provider configuration is required. The panel must be reachable from the Git provider for webhooks to deliver, and instances need outbound network access to pull the build helper image. Security-conscious operators can pin the helper image to a specific digest via the GIT_DEPLOY_HELPER_IMAGE setting instead of tracking the latest tag.
6. Unicast VXLAN: existing hypervisor groups keep multicast mode automatically. To use unicast, update the agents on every hypervisor in the group first, then switch the group's VXLAN mode in its settings.
7. Bandwidth overage: existing plans keep their current bandwidth behavior. To bill overage instead, edit a plan, select Charge Overage, and make sure the plan has a non-zero bandwidth allowance and a non-zero per-gigabyte rate.
8. Hypervisor TLS verification: verification is off by default for compatibility with self-signed agent certificates. If your hypervisor agents carry valid certificates, enable verification for the extra protection.