A startup's cloud bill often arrives in pieces: runtime, builds, database, networking, authentication, and the tools used to investigate failures. Forte consolidates hosting and its surrounding operating capabilities into one platform. That changes both which charges you compare and which integrations your team has to maintain.
Use one reference SaaS workload to see the difference. Price its runtime and metered activity, identify the capabilities included with Forte, and show application engineering separately. The example below is a budgeting model, not an average customer outcome.
Understand what the platform replaces
For a conventional hosted API, Forte supplies managed ingress, TLS, DDoS protections, deployment history, health checks, request metrics, and application-log retention. Customer authentication and Stripe-backed payments are available in the same project workflow. These capabilities reduce the number of infrastructure integrations a small team needs to set up before operating the product.
Availability within one platform does not make every operation free. Compute activity, builds, databases, payment transactions, and applicable messaging usage have their own pricing. Keep those lines visible while comparing what another provider includes or requires you to buy separately.
Define the reference workload
For a small SaaS estimate, record at least these inputs:
| Input | Example question |
|---|---|
| Runtime | How many always-available API instances, with how much CPU and memory? |
| Activity | How many instance-hours actively process requests? |
| Website | Static delivery or server rendering? How much traffic and egress? |
| Database | Engine, storage, connection count, backups, and availability target? |
| Identity | Monthly active users, MFA methods, email, and SMS volume? |
| Payments | Transaction count, value, payment method, refunds, and tax needs? |
| Delivery | Builds per month, duration, artifacts, health checks, and rollback? |
| Diagnostics | Log volume, retention, request records, metrics, and body capture? |
| Operations | Who responds to failures, maintains integrations, and tests recovery? |
Use the same region and availability target for each provider. If one option needs an additional gateway, certificate, log store, or identity vendor, put that line in its column rather than describing it as incidental.
Calculate the provider bill
Keep quantity, unit price, and subtotal visible:
monthly subtotal = quantity × unit price
monthly provider bill = sum(monthly subtotals)For Forte, the published default Service example is one provisioned instance with 0.5 GB memory at $5.11 per month, plus $0.05 for each hour that its 0.25 vCPU actively processes requests. Standard builds are $0.01 per build-minute on 4 vCPU build instances (a typical 10-minute build is $0.10) and Smart builds that run automatic configuration detection are $2.00. Shared database storage is $0.50 per provisioned GB-month, plus $0.20 per active vCPU-hour. These figures were reviewed against the Forte pricing page on September 10, 2026; use the pricing page as the current source.
A modeled Forte subtotal could be written like this:
| Line | Assumption | Arithmetic |
|---|---|---|
| API capacity | One default provisioned instance | 1 × $5.11 = $5.11 |
| API activity | 40 active vCPU-hours | 40 × $0.05 = $2.00 |
| Standard builds | 20 per month, ~10 minutes each | 200 build-minutes × $0.01 = $2.00 |
| Shared database storage | 2 GB | 2 × $0.50 = $1.00 |
| Database activity | 10 active vCPU-hours | 10 × $0.20 = $2.00 |
| Modeled subtotal | Before payments or messaging | $12.11/month |
This is arithmetic for stated inputs, not a prediction of a real application's usage. A busy API, additional provisioned instances, Smart builds, or a dedicated database changes the result.
Forte includes managed ingress, TLS, DDoS protections, request and app-log retention, metrics, and data transfer without separate add-on fees under its current published model. Other providers package those responsibilities differently. Link each external comparison to its current primary pricing page and record the retrieval date; avoid copying a calculator total without its settings.
Keep transaction costs separate
Payment-processing cost follows transaction value and method rather than compute usage. Forte's current documented fee is 5.5% + $0.55 per successful transaction, including card processing and sales-tax calculation, with custom rates available for larger accounts. Model it separately:
payment cost = successful payments × $0.55 + payment volume × 5.5%Do the same for email, SMS, and external API usage. A product with many low-value transactions can have a very different cost profile from one with a few annual invoices even when both run on the same container.
Show engineering time on another line
With Forte, your team configures a Service instead of maintaining its own container delivery pipeline, uses gateway session validation instead of operating session infrastructure, and opens request diagnostics without first assembling a request-to-log view. Those are specific changes in ownership. Their value depends on how much of that work you would otherwise build and maintain.
Engineering time is real but uncertain. Do not hide it inside an infrastructure percentage. List the tasks, estimated hours, and rate or opportunity cost separately:
| Task | Initial work | Recurring trigger |
|---|---|---|
| Build and deploy | Pipeline, artifact, health check, rollback path | Runtime/framework changes and build failures |
| Identity | Verification, sessions, MFA, recovery, administration | Policy, provider, and abuse changes |
| Payments | Confirmation, events, refunds, tax, reconciliation | Provider/API and business-rule changes |
| Diagnostics | Request IDs, logs, metrics, retention | New services and incident findings |
| Recovery | Backups, restore test, incident access | Scheduled exercises and architecture changes |
A fair model shows low, expected, and high estimates. It also acknowledges where a separate tool offers capability or control that an integrated platform does not.
Include migration and exit costs
The first month of a migration often includes both platforms. Add parallel runtime, data transfer where charged, engineering work, and risk controls. Then estimate the steady state. A lower future bill does not automatically justify a risky move during a critical release.
Portability also has value. Record which parts are ordinary application code and protocols, which are provider configuration, how data is exported, and how identity or payment state would move. The cheapest first month is not necessarily the lowest-cost three years.
Use the model as a decision record
Save the inputs and date beside the result. Review them when traffic, availability targets, staffing, or provider pricing changes. If two options are close, choose on operational fit rather than presenting uncertain arithmetic as precision.
You can review Forte's current rates and worked examples on Pricing and quotas, compare the operating models on Forte versus AWS, or plan a migration around your actual workload.