Technologies / Google Cloud
Google Cloud app development for mobile backends
Google Cloud app development, for a mobile product, means running the parts your app cannot do on the phone: the API it calls, the database it syncs with, the jobs that send notifications, resize images and settle payments. Below we cover what we run on Google Cloud, how it relates to Firebase, and when AWS or Azure is the better fit.
Google Cloud is one of the clouds in our mobile app development technologies hub. For the hands-on service of designing, provisioning and handing over cloud infrastructure, see cloud backend setup and hosting.
- Projects and billing in your name
- Cloud Run for containerised APIs
- Firebase and Google Cloud planned as one system
- Infrastructure defined in code
What Google Cloud does behind a mobile app
Most mobile apps need the same backend building blocks: somewhere to run API code, a database, file storage for photos and documents, a queue for background work, scheduled jobs, logs and alerts. Google Cloud provides each of these as a managed service, so your team spends its time on product logic rather than patching servers.
Our default shape is simple. A containerised API on Cloud Run, a database chosen for the data (Firestore for document-shaped, realtime data; Cloud SQL for PostgreSQL when the data is relational and reporting-heavy), Cloud Storage for media, Pub/Sub or Cloud Tasks for anything slow, and Cloud Scheduler for recurring jobs. Secrets live in Secret Manager. Everything is defined in Terraform so the whole environment can be rebuilt, reviewed or handed to another team.
Firebase and Google Cloud: one project, two consoles
This is the point most buyers miss. Firebase is Google’s platform for client-side developers, and several of its core products are Google Cloud products underneath. Per Google, Cloud Firestore, Cloud Functions and Cloud Storage are shared between the two, and billing and IAM are set per project. A Firebase project is a Google Cloud project.
In practice that means an app can start on Firebase (Authentication, Firestore, Cloud Messaging, Crashlytics) and grow into Google Cloud without a migration. When you need a proper API for payments, reporting or partner integrations, we add a Cloud Run service in the same project. It reads the same Firestore data and shows up on the same invoice.
What we watch for
Because the consoles look separate, teams sometimes create a second project for the “real” backend and end up with two sets of users, two billing accounts and duplicated data. We plan one project per environment (development, staging, production) from day one, with Firebase and Cloud resources together. Our Firebase app development page covers the client side of that setup in more depth.
When we choose Google Cloud, and when we do not
Google Cloud is our usual recommendation when the app already uses Firebase, when the team wants serverless containers without running Kubernetes, or when the product depends on Google services such as Maps and Play Integrity.
It is not automatically the right answer. If your company already runs on Microsoft 365 and needs staff to sign in with work accounts, Microsoft Azure is often simpler. If your organisation has an existing AWS estate, security reviews and reserved spend, building on AWS avoids a second cloud to govern. A second cloud doubles the IAM and audit work, so we rarely recommend one without a clear reason.
Choose Google Cloud if
- Your app is on Firebase or will start there
- You want containers without managing clusters
- Realtime sync with Firestore is central
- Your team is small and wants few moving parts
- You have no existing commitment to AWS or Azure
What we build on Google Cloud
Typical backend components on mobile projects, all inside your own Google Cloud organisation.
Cloud Run APIs
REST or GraphQL APIs in Node.js, Python or Go, packaged as containers with an OpenAPI contract shared with the app team.
Firestore data layer
Document models designed around screens, security rules reviewed with each feature, and indexes tracked in code.
Media pipelines
Signed upload URLs to Cloud Storage, then background resizing and moderation so the app never waits on a large upload.
Background jobs
Pub/Sub and Cloud Tasks for push fan-out, emails, webhooks and retries, with dead-letter handling so failures are visible.
Push notifications
Server-side sending through the FCM HTTP v1 API with service-account auth, plus APNs for iOS-specific needs.
AI features
Server-side calls to hosted models, with keys kept off the device, rate limits and logging of prompts and costs.
Cloud Run, Vertex AI and the services we use carefully
Cloud Run runs stateless containers and adds or removes instances as traffic changes. For a mobile API that is the right default: the same container runs locally, in CI and in production, and there is no cluster to upgrade. We still set concurrency, minimum instances and request timeouts deliberately, because the defaults are tuned for general workloads rather than your traffic.
Vertex AI is Google Cloud’s managed AI platform. We use it when a feature needs a hosted model inside your Google Cloud project, for example to keep data in one provider’s agreement. Model choice, region and pricing change often, so we confirm them in discovery.
One change matters for QA budgets. Google says Firebase Test Lab is deprecated and will shut down on 30 September 2027, and recommends the Developer Device Platform on Google Cloud. New projects should not build their device-testing pipeline on Test Lab.
Deciding between Firebase, Google Cloud and another provider?
Send us a short description of your app. Within one business day you get a recommended backend shape, which managed services it uses, and the trade-offs for your case.
Google Cloud compared with the alternatives
A buyer’s view of the four options we see most. Each is a sound choice for the right product.
| Google Cloud | AWS | Microsoft Azure | Firebase only | |
|---|---|---|---|---|
| Strongest at | Serverless containers, Firestore, Google services | Breadth of services, large existing estates | Microsoft identity, .NET, enterprise IT | Fast MVPs with little server code |
| Mobile starting point | Firebase in the same project | Amplify Gen 2 (TypeScript-defined backends) | App Service plus Notification Hubs | Client SDKs and Cloud Functions |
| Typical API runtime | Cloud Run containers | Lambda or containers | App Service or Container Apps | Cloud Functions |
| Best fit for | Firebase apps that outgrow it | Companies already on AWS | Companies on Microsoft 365 | Early validation |
| Watch out for | Duplicated projects and IAM sprawl | Service sprawl and complex billing | Licence and tier choices | Cost and query limits at scale |
Amplify Gen 2 became generally available on 6 May 2024, per AWS. Provider features change; we confirm current options in discovery.
Hiring and maintaining a Google Cloud backend
Engineers who know Cloud Run, Firestore and IAM are not hard to find, so handover risk is low if the setup is conventional. The risk is undocumented configuration made by hand in the console. We avoid that with infrastructure as code and a short runbook in the repository. If you want engineers on your own team, you can hire backend developers with a two-week trial.
Ongoing maintenance is predictable. Runtimes need upgrading on their own schedules (Node.js and Python versions in your containers), dependencies need monthly updates, and Google retires APIs from time to time. The FCM legacy APIs, for example, were deprecated on 20 June 2023 and shutdown began on 22 July 2024, so any backend still using them had to move to HTTP v1. We track these in your maintenance backlog, and our guide to the best backend for mobile apps compares upkeep across providers.
Code-quality practices on our Google Cloud projects
What you can check in your repository and cloud console.
- Separate projects for development, staging and production
- Terraform for every resource; no console-only changes
- Least-privilege service accounts, one per service
- Workload Identity Federation for CI, so no long-lived keys in GitHub
- Secrets in Secret Manager, never in the repo or app binary
- Budget alerts and per-service cost labels set before launch
- Structured logs, Error Reporting and uptime checks from the first release
- Firestore security rules tested in CI with the emulator
Google Cloud app development: frequently asked questions
Is Firebase part of Google Cloud?
Effectively, yes. Google describes Firebase as its platform for client-side developers, and Cloud Firestore, Cloud Functions and Cloud Storage are shared with Google Cloud. Billing and IAM are set per project, so a Firebase project is also a Google Cloud project. That lets an app start on Firebase and add Cloud Run services later without moving data.
Why use Cloud Run instead of Cloud Functions?
Cloud Functions suit small event handlers, such as reacting to a new Firestore document. Cloud Run suits a full API: many routes, shared middleware, a framework such as NestJS or FastAPI, and a container you can run locally and in CI. Most of our projects use both, with Cloud Run for the API and functions for small triggers.
Will our data and billing be in our own account?
Yes. We create projects inside your Google Cloud organisation, linked to your billing account. Our engineers get access through roles you can revoke at any time. Code is in your repository from day one and infrastructure is defined in Terraform, so another team can take over without asking us for anything.
Can you build AI features with Vertex AI?
Yes, when the feature needs a hosted model inside your Google Cloud project. Model choice, region and pricing change often, so we confirm them during discovery and record them in the architecture document. Calls go through your backend, never directly from the app, so keys stay private and you can log usage and cost per feature.
Should we use Google Cloud, AWS or Azure?
Start with what your organisation already runs. If you are on Firebase or have no cloud commitment, Google Cloud is usually the simplest path. If you already govern an AWS estate, stay there. If staff sign in with Microsoft work accounts or your systems are .NET, Azure is often the better fit. Running two clouds doubles the security work.
What does a Google Cloud backend cost to run?
It depends on traffic, data volume and design, so we do not publish a figure. The bigger driver is architecture: unpaginated Firestore reads, oversized minimum instances and chatty background jobs cause most surprises. We set budgets and alerts before launch and review costs after the first month. Our cost calculator gives a starting estimate for the build itself.
Get a Google Cloud backend your next team can run
Book a 30-minute scoping call. We will map your app’s data, integrations and traffic and recommend a cloud architecture, with the trade-offs written down.