Automated Cloud Run and Firebase Revision Cleanup

Introduction

Serverless platforms such as Google Cloud Run and Firebase Functions create a new revision each time you deploy new code or change configuration. Over time these revisions accumulate, consuming storage, inflating the UI, and making it harder to locate the active version. While the platforms automatically retain a limited number of recent revisions, many teams prefer a stricter policy that removes inactive or stale revisions on a regular basis. In this article we will explore how to set up an automated cleanup pipeline that runs on a schedule, identifies revisions that are no longer serving traffic, and deletes them safely. By the end you will have a reusable solution that keeps your Google Cloud project tidy, reduces cost, and improves operational clarity.

Why Revision Cleanup Matters

Every deployment to Cloud Run or Firebase creates a distinct revision identifier. These revisions are stored in the underlying container registry and metadata store, and each one adds a small amount of storage cost. More importantly, a large revision list makes it difficult to:

• Identify which version is currently receiving traffic.
• Audit changes for compliance or debugging.
• Maintain a clean CI/CD pipeline view in the Cloud Console.

Automatic cleanup eliminates manual housekeeping, prevents accidental rollbacks to obsolete code, and ensures that quota limits (such as the maximum number of revisions per service) are never reached.

Understanding Revision Lifecycle in Cloud Run and Firebase

Both Cloud Run services and Firebase Functions expose a listRevisions (or listVersions for Firebase) API that returns metadata including:

• Traffic allocation: Percentage of requests routed to the revision.
• Creation timestamp: When the revision was generated.
• Active status: Whether the revision is still referenced by any traffic split.

A revision is considered inactive when its traffic allocation is 0 % and it has not been the target of a recent deployment (e.g., older than 30 days). These criteria form the basis of the cleanup logic, ensuring that only truly unused revisions are removed.

Creating a Scheduled Cleanup with Cloud Scheduler

The most reliable way to run cleanup code on a recurring basis is to use Google Cloud Scheduler. The steps are:

1. Define a Pub/Sub topic (e.g., revision-cleanup) that will trigger the cleanup function.
2. Create a Cloud Scheduler job that publishes an empty message to this topic daily or weekly, depending on your project’s deployment frequency.
3. Set the job’s service account to have the run.revisions.delete and cloudfunctions.functions.invoke permissions.

This decouples the timing mechanism from the cleanup logic, allowing you to adjust the schedule without redeploying code.

Implementing the Cleanup Logic with Cloud Functions

The Cloud Function subscribed to the Pub/Sub topic performs the actual deletion. A typical implementation in Node.js looks like this:

• Initialize the @google-cloud/run client.
• Call listRevisions for each service, filtering by traffic=0 and creationTime < now - 30d.
• Iterate over the filtered list and invoke deleteRevision for each entry.
• Log successes and failures to Cloud Logging for auditability.

Because the function runs with limited concurrency, it can safely delete dozens of revisions in a single execution without hitting API rate limits. Adding exponential back‑off for transient errors further improves reliability.

Monitoring and Optimizing the Cleanup Process

After deployment, set up monitoring to ensure the cleanup behaves as expected:

• Use Cloud Logging alerts to notify you if a deletion fails more than a threshold.
• Create a dashboard that shows the total number of revisions per service over time, confirming that the count trends downward.
• Periodically review the retention policy (e.g., 30 days) and adjust based on release cadence.

Fine‑tuning the schedule (daily vs. weekly) and the age threshold can balance between aggressive cleanup and preserving a short rollback window. The same function can be extended to clean up other resources, such as old container images, by adding additional API calls.

Conclusion

Automating revision cleanup for Cloud Run and Firebase Functions removes manual overhead, curbs unnecessary storage costs, and keeps your project’s console organized. By understanding the lifecycle of revisions, configuring a Cloud Scheduler trigger, and implementing a focused Cloud Function that filters and deletes inactive revisions, you create a self‑maintaining system that scales with your deployment frequency. Continuous monitoring ensures the process remains reliable, while adjustable thresholds let you fine‑tune the balance between rapid cleanup and rollback safety. Implementing this pattern not only streamlines operations but also reinforces best practices for sustainable serverless management in Google Cloud.