How to Migrate a Django App to Google Cloud Run

Overview

Cloud Run can host Django as a containerized web service, but a successful migration requires more than building an image. The application must tolerate instance replacement, use external storage for durable data, and connect securely to its database and supporting services.

Inventory scheduled jobs, uploads, sessions, caches, database extensions, and network dependencies. Run the web service and background jobs as separate workloads when their scaling or execution characteristics differ.

Migration sequence

1. Containerize the existing application and run it locally with production settings.
2. Move uploaded media to object storage and keep the database outside the container.
3. Configure service identity, secret access, database connectivity, and egress requirements.
4. Run migrations as a controlled deployment step.
5. Configure concurrency, CPU, memory, minimum instances, and request timeout based on measured workload.
6. Shift traffic gradually and monitor errors, latency, instance restarts, and database connections.

Example: a concrete starting point

FROM python:3.12-slim
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# Replace config.wsgi with your Django project module.
CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8080"]

The example illustrates the boundary and validation pattern; adapt names, persistence, error handling, and provider-specific details to your application. It is not a complete production system by itself.

Failure cases to test

Do not use local container storage for files that must survive instance replacement. Scale-out can create more database connections than expected, so set connection limits deliberately. Check Cloud Run’s current limits and product behavior before choosing timeout or execution settings.

Before release, test the happy path, invalid input, missing permissions, dependency failure, and a retry or duplicate request where relevant. Record expected behavior so the implementation can be reviewed against the real business requirement.

When to bring in a developer

I can containerize and migrate a Django service to Cloud Run, including managed storage, database connectivity, job separation, and release validation.

Conclusion

The reliable version of this feature is not just the happy-path demo. It makes ownership, validation, authorization, failure handling, and operational behavior explicit. Start with the smallest useful workflow, measure it against real data, and expand only when the next requirement is clear.

Additional Resources

• cloud.google.com
• docs.djangoproject.com