Google Cloud Tasks with Rails Active Job

Using any serverless runtime? this is how to run Active Job via Google Cloud tasks using the latest version of the cloudtasker gem.

Arnaud Lachaume
Arnaud Lachaume LinkedIn
• 3 min read
Google Cloud Tasks with Rails Active Job

TL;DR; It is now possible to use Google Cloud Tasks with Active Job using the cloudtasker gem. If you intend to deploy your Rails app on Cloud Run, Cloudtasker is the easiest solution to get started with background jobs on Rails.

Serverless has become an integral part of deployment infrastructures nowadays. While not designed for it originally, Rails can easily be deployed in serverless mode using platforms like GCP Cloud Run.

Cloud Run takes care of scaling your applications automatically based on volume on concurrent requests and bills you per millisecond of CPU usage. It also allows you to scale down to zero instances, making it a perfect choice for test environments.

Your app is a bit slow to boot? Cloud Run also takes care of keeping a warm pool of instances to ensure your service doesn't suffer from slow starts.

For all the reasons above, Cloud Run is certainly one of the most (cost) efficient infrastructure to deploy your Rails app.

The problem? Well with serverless you can't rely on background processes anymore - everything must be managed as an HTTP request. If your application requires background jobs then traditional solutions such as Sidekiq or Resque will not work because they require an active daemon.

Introducing Cloudtasker

Comes cloudtasker, the easiest way to have background jobs for Rails on Cloud Run. We wrote previously about cloudtasker, but this time it's even easier thanks to a native Active Job integration for Rails.

Cloudtasker is an interface to Google Cloud Tasks, a Google-managed job scheduler. It allows you to enqueue and process jobs in exactly the same way as other background job solutions (Active Job, Sidekiq, Resque).

When you enqueue jobs using Cloudtasker, they get pushed to Google Cloud Tasks. When the job is due for processing, Cloud Tasks sends a webhook to your application to process the job. Because this whole enqueue/process logic is HTTP based, it's completely compatible with serverless deployments.

What about working locally then? We've got you covered. Cloudtasker is shipped with a local server that mimics Cloud Tasks so you can work locally without relying on ngrok to receive webhooks.

Getting started with Cloudtasker and Active Job

In order to run jobs locally with Cloudtasker you'll need to install and run Redis. Redis is only required when working locally with the local processing server, not in production.

Then add the following to your Gemfile:

Add an initializer to configure Cloudtasker:

Edit your config/application.rb and configure Active Job to use cloudtasker:

You're done with the setup part. Now let's define a job.

Launch Rails and the cloudtasker local processing server. This local processing server is only required in development to mimic Google Cloud Tasks locally.

Now launch a Rails console and try enqueuing your first job.

That's it! You should now see your jobs running in your logs.

Deploying to production

In order to deploy to production we'll need to add a few Cloud Task configuration details in our Cloudtasker initializer.

You should now create the Cloud Task queues in your project. Active Jobs will be pushed to the gcp_prefix-queue_as queue (e.g. myapp-critical). By default, this is gcp_prefix-default (e.g. myapp-default).

You can create your job queues via the Cloud Task UI, using the gcloud CLI or using the cloudtasker-provided rake task.

The bare minimum is to create the gcp_prefix-default queue.

Once you are done creating your queues, just deploy your app and enjoy seamless background jobs!

Kudos to the author

I'd like to thank Roberto Quintanilla for developing the Active Job integration. It's a really great addition to the gem.

About us

Keypup's SaaS solution allows engineering teams and all software development stakeholders to gain a better understanding of their engineering efforts by combining real-time insights from their development and project management platforms. The solution integrates multiple data sources into a unified database along with a user-friendly dashboard and insights builder interface. Keypup users can customize tried-and-true templates or create their own reports, insights and dashboards to get a full picture of their development operations at a glance, tailored to their specific needs.


Code snippets hosted with ❤ by GitHub

‍

Ready to Transform Your Analytics?

Join teams already using AI to make data-driven decisions faster than ever.

Most Recent Articles

The Distributed Monolith Tax: When One Jira Story Needs Pull Requests in Five Repositories

The Distributed Monolith Tax: When One Jira Story Needs Pull Requests in Five Repositories

Microservices promised independent teams. In many enterprises, a single Jira story still needs coordinated pull requests in four or five repositories. Learn what engineering leaders on Reddit say about distributed monoliths, lockstep releases and cross-repository changes, and how Keypup MCP links Jira issues to the pull requests that resolve them to measure how many changes span several repositories, what each extra repository costs in cycle time, and which repositories always change together.

Arnaud Lachaume
6 Best Engineering Metrics Software for Board Reporting (2026)

6 Best Engineering Metrics Software for Board Reporting (2026)

Compare the 6 best engineering metrics software for board reporting in 2026 — Keypup, Swarmia, Code Climate Velocity, Jellyfish, Faros and LinearB — on board-ready reporting clarity, business context mapping, non-technical accessibility, DORA Metrics, customization and AI capabilities. Learn which metrics belong in an engineering board report and how to translate them into language your board understands.

Liam Davis
The Headcount Paradox: Why Hiring More Engineers Didn't Speed Up Delivery

The Headcount Paradox: Why Hiring More Engineers Didn't Speed Up Delivery

Engineering headcount grew 50%, yet merged pull requests and delivered Jira issues barely moved. Learn what engineering leaders on Reddit say about hiring that slows teams down, and how Keypup MCP uses pull request, review and Jira data to show where the extra capacity goes: review queues, overloaded reviewers and work that now spans several repositories.

Arnaud Lachaume