PaaS Pricing: Usage-Based vs Fixed Instance Costs
PaaS pricing explained: compare per-minute usage with fixed instance fees, calculate CPU/RAM/disk cost, understand Dockup plans, and forecast safely.
PaaS pricing can look simple on a plan card and become confusing in production. A subscription fee may include usage credit, a fixed instance may charge for reserved size, and a usage-based platform may meter actual CPU, RAM, and disk. Comparing only the first dollar amount produces the wrong decision.
Dockup separates the plan subscription from metered consumption. Free includes starting credit; paid plans include monthly usage credit. CPU, RAM, and disk use are measured per minute and deducted from the balance.
What is the difference between usage-based and fixed instance pricing?
Fixed instance pricing charges for a selected machine or service size for the billing period, whether the application uses all reserved capacity or not. Usage-based pricing charges from measured consumption, sometimes with minimums or plan credits.
| Model | Main unit | Advantage | Risk |
|---|---|---|---|
| Fixed instance | Selected size over time | Predictable line item | Pay for idle capacity |
| Actual usage | CPU/RAM/disk consumed over time | Aligns bill with consumption | Variable forecast |
| Subscription plus credit | Plan fee and included balance | Combines access and spend | Credit can be misunderstood |
| Serverless request | Invocations/duration | Scales to zero for some work | Cost spikes at high volume |
| Seat plus resource | Team access plus compute | Collaboration features | Per-seat growth |
Dockup uses subscription plus usage credit. Paid-plan resource counts are unlimited, but compute and disk are not free. “Unlimited deployments” means no count limit on creating deployments; the resources they consume still use the plan balance.
Per-minute measurement is more granular than a monthly fixed instance. A service stopped for part of the month can consume less than one running continuously, while an always-on busy service can consume its available balance consistently.
What are the Dockup plans and included credits?
The plan table is:
| Plan | Price | Included credit | Workspace/database/deployment limits |
|---|---|---|---|
| Free | $0/month | $2.50 starting credit | 1 workspace, 3 databases, 3 deployments |
| Hobby | $5/month | $5 monthly usage credit | Unlimited on paid plans |
| Go | $20/month | $20 monthly usage credit | Unlimited; recommended |
| Pro | $35/month | $35 monthly usage credit | Unlimited |
CPU, RAM, and disk consumption draw from the balance. When evaluating a paid plan, think of the fee as both access to unlimited resource counts and a prepaid usage balance of the same amount.
The Go plan is recommended because it provides $20 of monthly credit while leaving room for several small services or a representative production workload. The right plan still depends on actual consumption.
Inspect account balance and service consumption in app.dockup.ai. Review CPU, memory, disk, and the current plan balance together rather than treating the subscription amount as the complete bill.
How do you calculate a realistic PaaS cost?
Build the estimate from workload-hours and measured resources.
A simple conceptual formula is:
monthly cost =
subscription
+ CPU consumption
+ RAM consumption
+ disk consumption
+ other metered services
- included usage credit
The exact unit rates belong in the current pricing source, not a copied spreadsheet that no one updates. The methodology remains stable.
For each service, record:
- Hours running per day.
- Average and peak CPU use.
- Average memory working set.
- Persistent disk size and growth.
- Database resources.
- Preview environment lifetime.
- Number of environments.
- Seasonal traffic.
- Expected build and deployment frequency.
Use measured values after launch. Requested memory is not the same as actual memory consumption on a usage-based model. Conversely, a fixed instance bill may reflect the requested size even when actual utilization is low.
Example workload worksheet
| Resource | Quantity | Running pattern | Confidence |
|---|---|---|---|
| Web service | 1 | 24/7 | High |
| Worker | 1 | 8 hours/day | Medium |
| PostgreSQL | 1 | 24/7 | High |
| Redis | 1 | 24/7 | Medium |
| Preview service | 3 average | 6 hours each | Low |
| Volume | 20 GB | Continuous | High |
Do not turn this table into a fake dollar benchmark without current unit prices and real utilization. It is a demand model.
When does usage-based pricing save money?
Usage-based billing is attractive when workloads are variable, can stop when idle, or have a large gap between requested ceiling and actual consumption.
Examples:
- Development environments used during working hours.
- Preview deployments that exist only during review.
- Batch workers active for a limited window.
- Early products with low baseline traffic.
- Services that can be stopped between campaigns.
- Small APIs whose average CPU use is low.
A fixed instance can be competitive when the workload is continuously busy and predictable. In that case, the team may value a stable reserved price over granular metering.
Usage-based savings require the workload to consume fewer resources in practice. Define a supported lifecycle for genuinely inactive development environments and verify current behavior in the platform instead of assuming that an idle-looking service has no cost.
Preview lifecycle also matters. A team that leaves dozens of previews running can erase the cost benefit of short-lived environments. Define ownership and expiration.
How do databases, volumes, and previews affect PaaS pricing?
Application compute is only one line.
Managed databases
PostgreSQL, MySQL, MongoDB, and Redis consume CPU, RAM, and disk. Database workloads are often always-on and storage grows over time. Include backups and migration requirements in the operational model even when they are not separate plan-count limits.
Persistent volumes
Volumes retain data across deployments and consume disk continuously. Monitor real usage:
dockup volume usage <volumeId> production/web --json
A 20 GB allocation with 2 GB used may indicate growth headroom or waste. The decision depends on how Dockup meters disk and the application’s near-term growth.
Preview deployments
Every PR or branch can receive an isolated environment and URL. A preview consumes resources while active. Private-network previews may also query the production database through an automatic read-only user, which can add database load even without a separate database.
Windows VMs and Linux boxes
OS-level compute can have a larger steady footprint than a small application container. Size from measured software requirements and shut down or retire temporary resources when their task ends.
Resource counts are unlimited on paid plans, so governance must replace hard count limits. An agent should not create ten test services merely because the platform permits it.
How do you compare PaaS providers without misleading yourself?
Normalize the workload first. A fair comparison uses the same:
- CPU and memory demand.
- Running hours.
- Database engine and storage.
- Persistent disk.
- Number and lifetime of previews.
- Team seats where charged.
- Network transfer assumptions.
- Backup and support requirements.
- Regions and availability model.
- Operational labor.
Then classify every line as fixed, metered, credited, or uncertain.
| Cost line | Provider A | Provider B | Dockup |
|---|---|---|---|
| Subscription | Record current | Record current | $0/$5/$20/$35 |
| Included usage | Record current | Record current | $2.50 start or plan-matched monthly credit |
| CPU | Fixed or metered | Fixed or metered | Metered per minute |
| RAM | Fixed or metered | Fixed or metered | Metered per minute |
| Disk | Record current | Record current | Metered per minute |
| Database | Separate or included | Separate or included | Managed resource consumption |
| Previews | Model lifetime | Model lifetime | Resource consumption while active |
| Seats | Record current | Record current | Verify current team plan terms |
Avoid three common mistakes:
- Comparing a production service on one platform with a sleeping free service on another.
- Subtracting included credit twice.
- Treating unlimited resource count as unlimited usage.
The Dockup vs Render vs Fly.io article applies this method without freezing competitor prices.
How should teams monitor and control PaaS spend?
Cost control is an operating loop. Review service consumption and account balance in app.dockup.ai, then connect changes to deployments, traffic, and resource growth.
Assign resource ownership. Every service, database, volume, Windows VM, Linux box, and preview should have a purpose and owner. Delete or stop unused resources through an approved process.
An AI agent can help by listing resources, summarizing usage, and proposing actions. It should not autonomously destroy resources based only on low activity. A stopped incident-recovery database or rarely used administrative service may be intentionally idle.
Budget thresholds
Define:
- Expected monthly range.
- Warning threshold.
- Investigation threshold.
- Approval required for new always-on resources.
- Maximum preview lifetime.
- Volume growth threshold.
- Owner for unexplained spend.
A forecast is a range, not a promise. Use high, expected, and low scenarios for traffic and preview activity.
Unit economics
Connect infrastructure spend to a product unit: active customer, processed job, API request, or generated artifact. Total cost can rise while unit cost improves. A fixed $20 subscription can also look cheap while unused services create operational complexity.
Cost of engineering time
A lower platform bill can be a worse decision if the team must build and maintain deployment wrappers, monitoring, preview orchestration, backups, or agent safety. Include operational labor and incident risk.
Dockup’s value proposition is not only the price table. It combines the deployment layer for AI agents with managed services and operations through one CLI.
A 30-day validation plan
- Start with the smallest plan that supports the test.
- Deploy a representative service and database.
- Run realistic traffic or workload.
- Keep previews only as long as normal review.
- Track usage weekly.
- Inspect volume and database growth.
- Compare projection with actual month-end spend.
- Move plans only from evidence.
The Free plan provides $2.50 starting credit for an initial validation. The Go plan provides a $20 monthly balance for a broader production test.
Final PaaS pricing decision
PaaS pricing is understandable when each line has a unit, time period, and ownership rule. Usage-based metering rewards efficient and intermittent workloads; fixed instances reward predictability when capacity is continuously needed.
Dockup’s per-minute CPU, RAM, and disk model should be evaluated from real service usage. Choose the plan that provides the appropriate included balance and account features, then continue measuring rather than assuming the subscription fee caps all consumption.
Use the Dockup CLI reference for current usage commands. Compare adjacent platforms in Dockup vs Railway and Dockup vs Heroku, checking their current official pricing before publication.
Separate cash flow from economic cost
Included credit changes when cash leaves the account, but it does not make the workload free. Track gross resource consumption and net amount due. Gross use reveals efficiency; net spend reveals cash impact.
For example, a Go subscription provides $20 of monthly credit. If measured resources consume less than the balance, the cash charge can remain the $20 subscription. If consumption exceeds the balance, the excess becomes additional spend. The exact result depends on current metering and account balance.
Use PaaS pricing reports that show both numbers so teams do not optimize only after credit is exhausted.
Model uncertainty explicitly
Early forecasts should have three cases:
| Variable | Low | Expected | High |
|---|---|---|---|
| Traffic | 50% of plan | Forecast | 200% of plan |
| Preview lifetime | 2 hours | 8 hours | 3 days |
| Database growth | 1 GB/mo | 5 GB/mo | 20 GB/mo |
| Worker activity | 2 h/day | 8 h/day | 24 h/day |
| Incident overhead | None | One recovery | Repeated debugging |
Multiply current unit rates through each case. The purpose is not precision to the cent; it is identifying which assumption can change the decision.
A fixed instance also has uncertainty: the team may outgrow the selected size and jump to the next tier. Include those step changes.
Include environment multiplication
A production architecture is rarely one service. Count staging, previews, workers, databases, Redis, volumes, Windows VMs, Linux boxes, and temporary migration resources.
One small service may fit comfortably in a starting credit. The same service across production, staging, and five persistent previews is a different PaaS pricing problem.
Define which environments run continuously:
- Production: normally always on.
- Staging: always on only when required.
- Preview: tied to an open PR or branch.
- Load test: created for a scheduled window.
- Migration: removed after validation.
- Disaster recovery: costed according to readiness target.
Unlimited counts on a paid plan make this governance more important, not less.
Compare optimization choices with risk
Reducing memory, stopping a worker, shrinking retention, or deleting a volume can lower spend, but each action changes reliability. Record the service-level consequence next to the estimated saving.
A useful optimization proposal contains:
- Resource and owner.
- Current measured consumption.
- Proposed change.
- Expected monthly range.
- Performance or recovery risk.
- Rollback method.
- Observation window.
An agent may summarize the measured consumption shown by the platform, but a human should approve changes that can affect availability or data retention.
Review PaaS pricing after architecture changes
A new cache can reduce database CPU while adding Redis cost. A background worker can improve API latency while running more hours. Private networking may change architecture without changing the same core CPU/RAM/disk units. A Dockerfile can reduce image size but consume engineering time.
Reforecast after:
- Adding a managed database.
- Enabling many previews.
- Attaching a large volume.
- Moving to Kubernetes autoscaling.
- Creating a Windows VM or Linux box.
- Changing retention.
- Launching a new region or customer tier.
PaaS pricing is a living model tied to architecture, not a one-time procurement spreadsheet.
Monthly review template
Record plan, starting balance, gross usage, remaining balance, top five resources, unexpected changes, stopped resources, preview count, disk growth, and next-month scenarios.
Compare the result with the previous month and annotate deployments or traffic events that explain the delta. This makes cost review useful to engineering instead of a finance surprise.
The same template can compare fixed instance providers: replace measured resource lines with selected instance fees and include utilization so idle capacity stays visible.
Publish assumptions with every estimate
A PaaS pricing number without assumptions is not reviewable. Attach running hours, resource use, disk growth, preview lifetime, database count, and current unit-rate date. Mark values measured, estimated, or unknown.
Update the model after the first week and first full month. The difference between forecast and actual is information about the workload, not merely an accounting error.
This discipline keeps PaaS pricing comparisons valid when providers change rates or the architecture grows.
Keep the model versioned
Commit the assumptions and review date beside architecture notes. A versioned PaaS pricing model shows why the team changed plans and prevents an old spreadsheet from becoming an unexplained budget target.
Start with a verifiable deployment
Deploy one representative workload, observe it for 30 days, and compare measured service, database, preview, and disk consumption with the plan balance.
Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.
FAQ
How much does Dockup cost?
Free is $0 with $2.50 starting credit. Hobby is $5 with $5 monthly credit, Go is $20 with $20 credit, and Pro is $35 with $35 credit.
What is unlimited on Dockup paid plans?
Paid plans allow unlimited workspaces, databases, and deployments by count. CPU, RAM, and disk consumption still use the plan balance.
How is Dockup usage measured?
CPU, RAM, and disk consumption are measured per minute and deducted from the account's included or topped-up balance.
Is usage-based pricing always cheaper than a fixed instance?
No. It can save money for variable or idle workloads, while a continuously busy predictable workload may compare well with a fixed instance. Model the same demand.
How should I compare two PaaS prices?
Normalize running hours, CPU, memory, disk, databases, previews, transfer, seats, and support; then identify fixed fees, metered use, included credits, and uncertainty.