Migration overview

The Cloud Foundry to Cloud Run migration guides provide background information on the differences between Cloud Foundry services and Cloud Run services, and show what you need to do to migrate Cloud Foundry applications to run in a container on Cloud Run. These migration pages do not cover data migration.

Cloud Foundry applications eligible for migration

Cloud Run is designed to run stateless HTTP or HTTP/2 applications. Your Cloud Foundry application cannot be migrated unless it meets the following criteria:

  • Uses HTTP or HTTP/2 (including gRPC).
  • Listens for traffic based on the PORT environment variable.
  • Doesn't require routing on different paths to different applications.
  • Doesn't require legacy Cloud Foundry "route services" for proxying traffic.
  • Doesn't require an instance ID or a particular startup order.
  • Doesn't need individual instances to be addressable.
  • Can be started without side-effects to the environment, for example, starting a database migration.

Understanding the differences between Cloud Foundry and Cloud Run

Although Cloud Foundry and Cloud Run both share a similar source deployment experience, there are crucial differences in how the platforms approach workload containerization, application configuration and service definitions. Cloud Foundry and Cloud Run differences are shown in the following table:

App Component Cloud Foundry Cloud Run
Container image deploy
Cloud Run
Source deploy Dockerfile
Cloud Run
Source deploy buildpacks
Containerization CF Buildpacks v2 N/A Cloud Build Cloud Build
Base Image cflinuxfs3 (Ubuntu 18.04)
cflinuxfs4 (Ubuntu 22.04)
Bring your own container image Dockerfile specified Ubuntu 18.04 or Ubuntu 22.04
Service Definition manifest.yaml service.yaml
Ignore list .cfignore .gcloudignore
Service Metadata VCAP_* environment variables Workload Identity, Cloud Secrets
Supported container formats Droplet Docker Image Manifest V2, Schema 1, Schema 2, and OCI formats

How to migrate

To migrate a Cloud Foundry application:

  1. Choose a strategy for building OCI-compliant containers
  2. Migrate to OCI-compliant containers
  3. Convert the manifest
  4. Attach backing services
  5. Deploy the service to Cloud Run

Sample migration

The Spring Music example uses core components of Cloud Foundry to rebuild Spring Music as an OCI compatible image and deploy it to Cloud Run. This sample follows the lift and shift OCI compliancy strategy.

What's Next

Choose your containerization strategy