Architecture decision
Why This Website Uses Firebase App Hosting
The platform was selected not simply because it is a Google product, but because it provides a proportionate path from a professional content site to a working cloud application.
Decision summary
Use Next.js with Firebase App Hosting to provide managed, GitHub-driven deployment today while preserving a practical path toward dynamic features and Google Cloud integrations later.
The website requirement
The objective was not merely to replace one marketing page with another. The website needed to become evidence that McQueen Cloud Advisory can design, build, document, and operate a credible cloud solution.
That means the platform must support professional content, case studies, interactive tools, secure intake workflows, analytics, and future integration with the consultation preparation system.
- Support a modern Next.js application rather than a fixed website template
- Deploy automatically from a version-controlled GitHub repository
- Preserve a path toward forms, assessments, and backend integrations
- Remain primarily managed rather than requiring server administration
- Integrate naturally with Google Cloud and Firebase services
- Provide traceable builds and repeatable production deployments
Options considered
Each option could host some version of the site. The question was which one best fit both the current need and the intended direction without adding unjustified complexity.
Google Sites
Strength
Very low maintenance and appropriate for basic informational content.
Limitation for this project
Insufficient control over application behavior, source control, automated testing, and custom integrations.
Firebase Hosting
Strength
A strong option for static websites, static assets, and single-page applications.
Limitation for this project
The project is intended to grow beyond purely static content and may use server-rendered or backend-connected functionality.
Cloud Run
Strength
Provides extensive control over containerized applications, runtime configuration, and backend services.
Limitation for this project
Introduces more direct infrastructure and deployment responsibility than this website currently requires.
Firebase App Hosting
Strength
Combines framework-aware builds, GitHub integration, managed deployment, and access to the broader Google Cloud ecosystem.
Limitation for this project
Requires billing to be enabled and abstracts some of the underlying Cloud Run and build configuration.
Deployment architecture
The source repository remains the system of record. A push to the production branch triggers a managed build and rollout rather than a manual upload.
Firebase App Hosting uses Google-managed build and runtime services beneath the Firebase interface. This preserves a relatively simple developer workflow while still producing a containerized deployment with traceable rollouts.
Why App Hosting was selected
App Hosting was the smallest managed platform that satisfied the intended direction of the website without requiring a custom container deployment process from the beginning.
It supports the current Next.js application, connects the live environment to GitHub, and leaves room for server-side functionality, secrets, Firestore, and Cloud Run services as those needs become real.
The decision is therefore based on architectural fit rather than brand preference. A different project with different requirements could justify Firebase Hosting, Cloud Run, or another platform entirely.
Tradeoffs and limitations
The current site is mostly static
Firebase Hosting could serve the present content effectively. App Hosting was selected because the intended destination includes dynamic workflows and application features, not because every current page requires server execution.
Managed infrastructure reduces direct control
App Hosting makes deployment easier by managing the build and runtime path. The tradeoff is less direct control than operating a customized Cloud Run deployment.
Billing must be enabled
App Hosting requires a billing-enabled Firebase project. Usage and cost still need to be monitored even when the application remains small.
Convenience does not replace architecture
A managed platform simplifies operations, but security, data handling, service boundaries, and application design still require deliberate decisions.
When the decision should be revisited
Architecture decisions are not permanent truths. The platform should be reconsidered when the assumptions behind the choice materially change.
- The website becomes entirely static with no planned backend features.
- The application requires specialized container or networking configuration.
- Multiple backend services need independent deployment and scaling.
- Infrastructure must be managed through a broader organization-wide platform.
- Cost, compliance, or regional requirements no longer fit the service.
Official references
The implementation and platform descriptions in this article are based on the official Firebase documentation.
Core lesson
Choose the platform that fits the operating requirement—not the one with the longest feature list.
The right architecture is the smallest design that credibly meets the current need while preserving a reasonable path toward known future requirements.
Evaluate your architecture in context
Not sure whether your cloud platform is the real constraint?
The readiness assessment evaluates cloud architecture alongside data, workflow, governance, AI, and internal support capability so you can identify the area most likely to limit progress before committing to a platform change.