Cloud Free Tiers for Web Apps: Cloud Run, Firebase & MongoDB

Launching an application does not require committing to a large hosting bill on day one. For a public site, a proof of concept, or an early-stage product, cloud free tiers can provide a capable foundation—provided we understand their limits and design for a sensible next step.

That is the approach behind emz-systems and the Demo Apps Portal. We use managed services for the concerns they solve well, keep the architecture intentionally small, and watch the thresholds that would make a paid plan worthwhile. The objective is not “free forever”; it is a secure, maintainable starting point with predictable growth.

This separation keeps responsibilities clear. No single provider has to solve every problem, and individual components can evolve when the project needs them to.

The frontend stack

The two front ends use different approaches because they have different jobs. The public site benefits from static, content-focused pages; the portal needs client-side state, routing, and sign-in.

These are the limits worth watching. They are not forecasts of cost; they are the signals that tell us when to investigate an upgrade.

Traffic alone is not necessarily the reason to upgrade. The more useful triggers are exceeding that request limit, needing more CPU time, or requiring more advanced platform and security features. Cloudflare’s paid Workers plan starts at $5 per month and increases those limits. Read the current Workers limits.

The no-cost Spark plan is a good starting point. Several services remain free at scale, while other products provide a usage allowance. Cloud Firestore, for example, has no-cost daily allowances for reads, writes, and deletes. The important detail is that Spark-plan usage is capped: when a quota is exceeded, that product stops until the next billing cycle. Moving to Blaze enables pay-as-you-go use, so budgets and alerts should be configured before that upgrade. See Firebase’s current plan details.

It is a sensible fit for early demo data, application metadata, and modest workloads. Upgrade when the application needs more capacity, predictable performance, production-grade operational controls, or database capabilities unavailable on the shared tier. Free clusters also have feature constraints—for example, aggregation pipelines cannot write temporary files to disk. Review Atlas Free cluster limits.

Cloud Run’s free allowance for request-based billing currently includes 2 million requests, 180,000 vCPU-seconds, and 360,000 GiB-seconds of memory per month. A lightly used API that scales to zero can sit comfortably within that allowance. A constantly active service, long-running processing, large memory allocations, or significant outbound traffic will reach paid usage sooner.

The first backend deployment should include cost controls as part of the design: sensible memory and CPU limits, minimum instances set to zero unless needed, billing budgets, and monitoring of both Cloud Run and database usage. See Cloud Run pricing and free-tier details.

Its free plan currently includes 50 submissions per month, unlimited forms and projects, notification delivery to up to two email addresses, and 30 days of submission history. For a small business site, that is often enough. If the contact form regularly exceeds 50 genuine enquiries each month, a paid plan is a straightforward and positive next step. Check Formspree account limits.

Unlike the other services here, Clarity has no paid threshold to plan for. Microsoft describes it as free forever, with no traffic limits, no sampling, and no forced upgrade. The key consideration is privacy: use appropriate consent and privacy notices, and make sure sensitive information is not captured. Read the Microsoft Clarity FAQ.

Free plans reduce the cost of learning, experimentation, and early delivery. They do not remove the need for capacity planning. Our approach is to use them while they fit, track usage before limits become a problem, and upgrade the specific component that has outgrown its allowance.

1. Start with managed services and low operational overhead.
2. Monitor usage and configure alerts before enabling pay-as-you-go services.
3. Upgrade when the application’s value and requirements justify it.
4. Keep the architecture modular so growth in one area does not force a rebuild everywhere else.

That gives emz-systems and the Demo Apps Portal room to build real applications today, while keeping a clear path for the Spring Boot backend and whatever comes next.

Provider limits and pricing change. The figures in this post were checked on 16 August 2026; always confirm the current provider documentation before making a cost decision.