DigitalOcean App Platform Legacy Plans in 2026: Stay, Migrate, or Self-Host?

DigitalOcean has not announced a migration date for App Platform’s legacy plans. It has done something more difficult to plan around: the current documentation says those plans will be deprecated “soon,” while leaving existing customers to decide whether to move before the switch is made for them.

For a small team, the answer is not automatically “leave.” The new plan structure is cheaper or similar for many workloads, and it usually includes more egress. But the decision is easier when the bill is explicit. In a representative three-app setup, staying on legacy pricing costs $67/month, opting into the closest current plans costs $64/month, and a conservative six-node, high-availability Hetzner cluster costs about €43.43/month in infrastructure before databases, backups, and operator time.

Those are different products, not interchangeable line items. App Platform includes the control plane and deployment experience. The Hetzner number is the cost of the capacity on which a self-hosted platform can provide those layers. The point of the comparison is to expose the premium and the control it buys, not to pretend that Kubernetes administration is free.

The three-way bill, before the migration debate​

Here is the worked example used throughout this post:

• Three production web services, each using one shared vCPU and 1 GiB of RAM.
• 600 GiB of outbound traffic per month across the team.
• One dedicated egress IP for an external service that allowlists the application.
• Always-on production capacity, with a high-availability self-hosted option.
• Prices exclude tax and database costs.

DigitalOcean’s legacy professional-xs plan is $12/month and includes 100 GiB of transfer. Three services therefore have a 300 GiB pooled allowance. The bill is:

The DigitalOcean figures follow its current pricing documentation: transfer is pooled at the team level, overage is $0.02/GiB, and a dedicated egress IP costs up to $25/month per app. The Hetzner figure uses the current EU price for a CX23, six nodes to leave room for three control-plane and three workload roles, six IPv4 addresses, and one managed load balancer. It is an infrastructure estimate, not a claim that six small virtual machines reproduce every App Platform feature.

The currency difference matters. Do not read €43.43 as an exact exchange-rate conversion of $64. It is a transparent vendor-price comparison: the hosted bill is in DigitalOcean’s published dollars, and the capacity bill is in Hetzner’s published euros. Your region, tax treatment, and availability can move either number.

What staying on the legacy plan really costs​

Legacy status is determined by the app’s creation date. DigitalOcean’s documentation says legacy plans apply only to apps created before May 7, 2024. The old table has two broad families:

The surprising part is that “legacy” does not mean “currently more expensive” across the board. A Basic-XXS maps closely to a current $5 fixed shared container and gets 50 GiB instead of 40 GiB. A Professional-XS remains $12 in the current structure but gets 150 GiB. Some larger shared mappings cost more: Basic-S moves from $20 to a $25 current 2 GiB container, while a dedicated 4 GiB workload can move from the $75 Professional-1L plan to a $49 current dedicated container.

That makes waiting look harmless if you only inspect this month’s total. For many teams, voluntary migration is a modest change or an improvement. The cost of staying is the uncertainty around a plan DigitalOcean has already announced it intends to deprecate.

There is an important distinction here. The documentation does not publish a fixed forced-migration date, and it does not promise that legacy customers will receive no future features. It does show the legacy plan matrix separately and recommends the new plans for new or upgraded apps. A responsible cost model should therefore price the known bill and separately record the unknown: how much notice, testing time, and production risk will accompany the eventual change.

Egress is the variable that changes the answer​

At low traffic, the three hosted choices can be nearly identical. At higher traffic, the allowance—not the container price—becomes the lever.

Using the same three 1 GiB services and one dedicated egress IP, the monthly sensitivity looks like this:

The formula is simple:

hosted total = component prices + dedicated IP + max(traffic - pooled allowance, 0) × $0.02

At 150 GiB, neither hosted option has an overage charge, so the migration produces no monthly saving. At 600 GiB, the current plan saves $3 because its pooled allowance is 450 GiB instead of 300 GiB. At 2 TiB, both plans are paying overage, but the current plan still saves $3 because the allowance delta is only 150 GiB.

This is why a move to current pricing is not the same as an escape from metered egress. It improves the threshold; it does not remove the meter. If your traffic is mostly cacheable static content, a CDN may reduce the application’s outbound count. If it is API responses, media, or agent-generated artifacts, measure the actual transfer rather than extrapolating from request volume.

The dedicated IP is a separate decision. Remove it from both hosted totals and subtract $25. If three different services each need their own allowlisted egress identity, add $75 instead. DigitalOcean documents dedicated egress IPs as an app-level feature, so this is one place where “three small apps” can cost materially more than “one larger app” even when their container resources are identical.

What the Hetzner number includes—and leaves to you​

The self-hosted estimate uses six CX23 servers in a European Hetzner location. Each current CX23 is listed at €5.49/month before IPv4, with 2 vCPU, 4 GiB RAM, and 20 TB of included traffic. Six nodes cost €32.94. Six IPv4 addresses add €3.00 at €0.50 each, and one LB11 adds €7.49 in the model above.

Cluster API does not turn that capacity into a PaaS by itself. It gives an operator declarative APIs and controllers for creating, scaling, upgrading, and deleting Kubernetes clusters. Cluster API Provider Hetzner supplies the infrastructure-specific machine lifecycle. The application layer still needs ingress, TLS, builds, logs, secrets, policy, rollbacks, and a user-facing deployment workflow.

The six-node shape is intentionally conservative for a production comparison:

• Three control-plane nodes allow the Kubernetes API to survive a single-node failure.
• Three worker nodes give application workloads somewhere to run when a control-plane node is unavailable.
• A shared load balancer gives the three applications one public entry point and keeps ingress out of the node-IP arithmetic.
• The 120 TB aggregate allowance is vastly above the 300–450 GiB allowances in the hosted example, so the modeled 600 GiB workload has no egress line item.

There are cheaper ways to start. A three-node converged cluster would reduce the node subtotal to €16.47 and the IP subtotal to €1.50, producing roughly €25.46 with one LB11. But that is a different availability posture: control-plane and application workloads compete for the same nodes, and a node loss removes a larger fraction of capacity. The cheaper number is useful for staging or a team that accepts that trade; it should not be presented as equivalent HA.

The estimate also excludes the costs that make self-hosting a real operating decision: a database and its backups, object storage, monitoring retention, security response, incident time, and the engineer who maintains the platform. Bex, Coolify, or a homegrown deployment layer can reduce the amount of product work, but none of them removes the need to own the failure modes. DigitalOcean’s App Platform price is buying that operational surface as well as compute.

Three sensible responses to an undated deprecation​

Start with the least disruptive path.

1. Inventory the app. Record its creation date, legacy plan slug, component count, monthly outbound traffic, database attachment, dedicated-IP requirement, and deployment/rollback assumptions.
2. Run the current-plan calculation. Use the closest current container size and include the team-wide egress pool. A $3 saving is not a migration strategy by itself, but a $20 or $100 recurring difference may justify a planned test.
3. Opt in before you are forced to test. Create a staging app on the current structure, deploy the same image or repository, test outbound allowlists, and verify the app spec retains any dedicated egress configuration. DigitalOcean warns that omitting that setting can release the IP permanently.
4. Model self-hosting only at the right scale. Start with the smallest honest availability target. Include nodes, IPs, ingress, storage, backups, and a labor budget. Treat the resulting number as a floor until you have measured operations for a month.
5. Choose based on control, not a slogan. Stay managed when the control plane, support, and low migration effort are worth the premium. Move when predictable capacity, pooled bandwidth, infrastructure ownership, or a vendor-independent change window matters more.

The absence of a date does not make DigitalOcean’s legacy plans an emergency. It does make them a poor place to hide a long-term assumption. A voluntary move to the current structure may cost nothing monthly and buy more transfer headroom. A self-hosted move can reduce the infrastructure bill substantially for a team with enough applications to fill a cluster, but it also transfers every operational responsibility that App Platform currently absorbs.

That is the useful conclusion in 2026: the legacy bill is not necessarily the expensive option. The expensive option is discovering your migration path only after someone else has selected the date.

Bex.co is an open-source, AI-native Render alternative for teams that want the deployment workflow on machines they control: push a git repository and get a running HTTPS service without a vendor-controlled plan-migration clock. Star the repo on GitHub or learn more at Bex.co.

Sources​

• DigitalOcean App Platform Pricing Documentation
• DigitalOcean App Platform Pricing Page
• DigitalOcean App Platform Features
• DigitalOcean: How to Add Static IP Addresses to App Platform Apps
• Hetzner Cloud Pricing
• Hetzner Price Adjustment 15 June 2026
• Hetzner Cloud Load Balancers
• Kubernetes Cluster API documentation
• Cluster API Provider Hetzner documentation