Production Application — Applications and databases

What this tier is

The jump from starter to production is not mostly about resources. It is about what happens during a deploy and what happens when one instance dies. This tier runs at least two replicas behind health checks, so a rolling deploy does not drop requests and a crash does not become an outage.

It also includes a staging environment configured the same way as production, including the same runtime version and the same environment variable shape, so that testing on staging actually tells you something.

Specification

Production Application specification
Compute	2+ replicas, 2 vCPU equivalent pooled
Memory	4 GB pooled across replicas
Storage	40 GB persistent
Database	Managed MariaDB or PostgreSQL, 25 GB, pooled connections
Environments	Production plus matched staging
Deploys	Rolling, health-checked, auto rollback on failure
Workers	Background workers and scheduled jobs included
Backups	Daily dump plus binary log retention, 30 days

What is included

Two or more application replicas with liveness and readiness checks
Rolling deploys with automatic rollback on failed health checks
Staging environment matching production configuration
Managed database with a larger allocation and connection pooling
Scheduled jobs and background workers alongside the web process
Log retention with operator access for incident review
Resource metrics and alerting on restart loops and memory pressure

Typical use cases

A customer-facing application where downtime has a cost
A B2B tool with contractual availability expectations
An API with third-party integrations that retry badly
An application that outgrew a single container and a hope

Responsibility split

Written down so there is no argument about it later.

We handle

Replica scheduling, health checking, and rolling deploy mechanics
Database sizing, tuning, backup, and restore execution
Platform patching, node maintenance, and capacity headroom
Alerting on platform-level failure and incident communication

You handle

Making your application safe to run as more than one instance
Schema migrations that tolerate a rolling deploy
Application-level monitoring of your own business logic

How provisioning works

Operator-provisioned with a short design conversation first. We agree replica count, health check endpoints, migration strategy, and the staging shape before building. Typical turnaround is two to three business days.

Order

Billing period

$59/mo billed each month $590/yr 17% less than monthly

Email address

We use this for the invoice, provisioning updates, and account sign-in.

Image or repository

Database engine

Anything we should know

Migration deadlines, existing stack, constraints.

Payment is handled by Stripe. We never see or store card details. Continuing means you accept the Terms, Acceptable Use Policy, and Privacy Policy.

Ask a question first

Other tiers in Applications and databases

Entry

Application Starter

One application container and one managed database, wired together.

$19 /mo

Application container plus a managed database schema
Private in-cluster networking to the data tier
Daily database backup with a fourteen-day restore window

View details

Managed MariaDB

A dedicated schema on our data tier, backed up and patched by us.

$8 /mo

Dedicated schema and credentials, not a shared database
Daily logical backup with a fourteen-day restore window
Engine patching coordinated with you in advance

View details

Managed PostgreSQL

A PostgreSQL database with extensions, backups, and an operator.

$10 /mo

Dedicated database and role with least-privilege grants
Common extensions available on request
Daily backup with a fourteen-day restore window

View details

Managed Cache

A Redis-compatible cache with an eviction policy you chose on purpose.

$6 /mo

Dedicated instance, not a shared keyspace
Eviction policy and memory ceiling agreed at provisioning
Private in-cluster access, never exposed publicly

View details