Dev 1. A focused starting point.

A focused environment with a bounded job

Use Dev 1 as a candidate for a compact API or a functional staging exercise with synthetic data. Keep active components and concurrency explicit. A database, multiple workers and overlapping releases can exhaust a small budget even when average traffic is light.

When to choose a different shape

Reconsider this profile when your representative workload needs concurrent memory that leaves no host or release reserve. A large database migration or performance rehearsal should be sized for that task, not forced into the smallest allocation.

Understand the option you are changing

CPU, memory, working storage, monthly transfer and IP choices solve different constraints. Backups are a separately priced option; extra disk alone is not independent recovery. Compare all recurring options before increasing the budget.

Check the next release as well as today’s traffic

Record artifact, schema changes, worker behavior and temporary space. Use the relevant operating guide to choose a measurable next step.

When this profile makes sense

Choose this when memory use is modest and you can measure demand before adding capacity.

Use a representative workload to validate memory peaks, disk needs, and CPU demand. No benchmark, traffic capacity, or guaranteed application performance is claimed.

What you manage

Choose the Linux image, install and update your application, and keep your own access, monitoring and recovery process. Actual supplier images and availability still need confirmation.