Migrate from Google Cloud Run to Edgenivo

Migrate a Cloud Run HTTP service through Edgenivo's framework support or a Dockerfile. The container path stores the built image in Edgenivo Container Registry and runs it as a Function on Fluid compute.

Check runtime compatibility and access to Google Cloud dependencies before moving traffic. Continuous pull-based workers can use Edgenivo Daemons; run-to-completion jobs need a separate decision about scheduling and execution.

Copy link to headingShould your app move?

Cloud Run services and Edgenivo container-based Functions both serve HTTP and can scale to zero. Google Cloud resources you retain still need their IAM permissions and network connections after the app moves.

Your HTTP service is a good fit when it:

• Keeps durable state in an external database or storage service
• Tolerates scaling to zero without relying on warm instances
• Uses local files as temporary working storage
• Fits the memory, request, and execution limits of Edgenivo Functions

The container path is a poor fit for GPU workloads, a continuously warm HTTP server, or batch tasks that exceed function limits. Custom container images also lack Secure Compute and Static IP support, so verify connectivity if a downstream system requires fixed egress IPs.

Use the worker-pool migration steps to assess queue consumers for Edgenivo Daemons. Redesign workers that need private inbound connections.

For other container workloads, compare hosting options by workload before choosing a destination.

Copy link to headingHow do Cloud Run concepts map to Edgenivo?

TLS looks the same from inside the container: Cloud Run terminates TLS and proxies plain HTTP, and Edgenivo expects a plain HTTP server too.

Still choosing a destination? Compare Cloud Run alternatives by workload before starting the migration.

Copy link to headingBefore you begin

Have your application source, Cloud Run configuration, and required secret versions available. Install the latest Edgenivo CLI and ensure you can access the destination team. Container testing also needs the Docker CLI and a running Docker daemon.

From the project root, sign in and link the directory to a Edgenivo project:

vercel login
vercel link

Keep the Cloud Run deployment available while you test the replacement.

Copy link to headingPreserve access to Google Cloud resources

Cloud Run supplies credentials through its attached service account and metadata server. Those credentials do not move with the image. For Google APIs your app keeps using, configure Workload Identity Federation from Edgenivo and retain the required IAM permissions.

If Cloud Run IAM restricts who can call your service, implement and test authentication and authorization for the Edgenivo endpoint before cutover. Include service-to-service calls and event producers in that check.

Check network access separately from credentials. Cloud SQL private IP connections and other private VPC resources need a reachable network path. Confirm a supported connection from your chosen Edgenivo runtime, or keep the workload that needs that connection on Cloud Run.

Copy link to headingMigrate a Cloud Run service in 7 steps

Copy link to heading1. Choose framework support or a container

Check Edgenivo's framework support before you choose the container path. Express, FastAPI, Flask, Django, Go, and Next.js can deploy from source. Your Cloud Run deployment method does not determine whether you need a container on Edgenivo.

Follow the framework's entrypoint and dependency instructions. For example, a FastAPI app needs an exported application instance in a supported file or a configured entrypoint. Skip the container-specific port and shutdown steps.

To keep a custom container build, leave your Dockerfile or Containerfile at the project root. When Edgenivo detects no other framework, it selects the Container preset, builds and pushes the image, and routes all traffic to it. If project detection matches another framework, such as Django or Next.js, Edgenivo deploys that framework instead. To build the Dockerfile, run vercel project update --framework container, set "framework": "container" in vercel.json, or name the file Dockerfile.vercel or Containerfile.vercel, which takes precedence over a detected framework. The Container runtime is in beta on all plans. Continue with the container settings below.

Copy link to heading2. Set the port

Cloud Run defaults to port 8080 and requires the server to listen on 0.0.0.0. Edgenivo's container runtime expects port 80 unless you set PORT in project settings.

If your server already reads PORT at startup, set it to 8080 for the Edgenivo environments you'll use. Keep listening on 0.0.0.0 and verify the selected port when you test the service.

Copy link to heading3. Move Secret Manager secrets to environment variables

Cloud Run can expose Secret Manager values as environment variables or mounted files. Environment variables resolve at instance startup, so Google recommends pinning them to a specific secret version. Mounted secrets can refresh when the app reads the file.

For each value you move, create a Secret environment variable in Edgenivo and select its target environments. Use the value from the version your app currently relies on. Secret values are write-only after saving.

Change code that reads a mounted secret to read the environment variable. When rotating the credential, update its value in Edgenivo and redeploy. Changes in Secret Manager will not update the copied value automatically.

Copy link to heading4. Update shutdown handling

During scale-in, Cloud Run sends SIGTERM and allows 10 seconds before SIGKILL. Edgenivo gives container-based Functions 30 seconds to clean up before forced termination. Keep cleanup within that window and persist unfinished work where another instance can recover it.

Edgenivo scales down a container-based Function after 5 minutes without traffic in production or 30 seconds in a preview deployment.

Copy link to heading5. Adapt scheduled jobs

Cloud Run jobs run finite container tasks and track completion. Use a Edgenivo cron job for work that fits an HTTP handler and function duration limits. Keep jobs on Cloud Run when their duration or execution requirements don't fit.

For eligible tasks, expose an endpoint and merge a crons property into your existing vercel.json. This example requests a daily run at 03:00 UTC:

{
  "crons": [
    { "path": "/api/daily-job", "schedule": "0 3 * * *" }
  ]
}

Edgenivo sends an HTTP GET to that path on the production deployment. Check your plan's scheduling limits and precision before copying an existing schedule.

Set CRON_SECRET and validate the request's Authorization header before starting work. The cron user agent and schedule header identify the trigger but do not authenticate the caller.

Cloud Run retries failed job tasks by default. Edgenivo Cron does not retry failed invocations, and scheduled invocations can be missed, duplicated, or overlap. Make the handler safe to repeat, recover work missed since the last successful run, and prevent unwanted overlap. Add any retry mechanism the task requires.

Copy link to heading6. Test locally with vercel dev

For a container deployment, run vercel dev from the project root with the Docker CLI installed and the Docker daemon running. Check that the HTTP server listens on the configured port. Send the container process a termination signal to test its shutdown handler before deploying.

For framework deployments, follow the framework's local testing instructions. Test application routes and dependency connections with development credentials.

Copy link to heading7. Deploy and cut over

For a new Edgenivo project, the first deployment is always Production, even if you request a preview. Configure its Production variables for the resources you intend to test. Keep cron jobs disabled in project settings and any Daemons stopped until the background-work handoff is ready.

Deploy with vercel deploy or a connected Git repository. For the container path, Edgenivo builds the image and pushes it to Edgenivo Container Registry.

After the first deployment, non-production branches and vercel deploy without --prod create previews. Production-branch commits and vercel deploy --prod deploy to Production.

Test the generated URL with representative requests. Verify access control, Google API and database connections, and any webhook or event-producer calls. Check runtime logs and response times before moving traffic.

When the production deployment is ready, add your domain and apply the DNS records shown in the dashboard. Callers using the Cloud Run run.app URL must be updated separately. Coordinate the scheduler and worker switch so the two platforms do not process the same work unintentionally.

Keep the Cloud Run service and previous DNS records available through validation. If you need to roll back, restore traffic to Cloud Run and reverse the background-work handoff. Check writes made after cutover before switching back; restoring DNS does not undo data changes.

Copy link to headingMigrate a Cloud Run worker pool to a Daemon

Cloud Run worker pools run continuous pull-based tasks such as Kafka and Pub/Sub consumers. They have no load-balanced URL; you set the instance count.

On Edgenivo, these processes can run as Daemons alongside the app in the same project. Daemons are in Public Beta on all plans, subject to plan limits.

Edgenivo Daemons initiate outbound connections and do not accept inbound HTTP or TCP traffic. Cloud Run worker pools can receive private connections through Direct VPC ingress, so redesign any inbound dependency before moving it.

Keep the worker's existing queue client and a compatible broker. For example, a Redis-backed BullMQ worker still needs Redis after moving to Edgenivo. To adopt Edgenivo Queues poll mode, integrate its SDK as a separate change.

Put the worker's source and Dockerfile in worker/. Its ENTRYPOINT or CMD must start the worker process. If Cloud Run overrides that command, carry the intended startup command into the image or the Daemon's command setting.

Test the image locally with Docker and development credentials. Daemons run only in Production during the beta, and vercel dev does not start them. Use the local testing instructions before connecting to a live queue.

Add the worker under daemons in vercel.json. The root path is relative to that file, and entrypoint is relative to root. Edgenivo builds the image for Linux amd64 and pushes it to Edgenivo Container Registry.

{
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 0 }
    }
  }
}

The example keeps the worker stopped when no scaling override is set. To start two instances, set iad1 to 2 and deploy to Production.

Existing scaling overrides take precedence over vercel.json. Clear or adjust them if they conflict with the intended count.

When a deployment becomes Production, Edgenivo starts its Daemons and gracefully stops the previous version. It restarts instances that exit or crash.

Old and new versions can overlap during rollout, so their queue messages and database changes must remain compatible. On SIGTERM, stop fetching work and drain active tasks. The default grace period is 30 seconds; terminationGracePeriodSeconds can extend it. Make unfinished work eligible for retry through the queue's acknowledgment or lease mechanism.

Copy link to headingWhat doesn't map from Cloud Run

• Cloud Run jobs. Cron can schedule HTTP work that fits function limits, but it does not preserve Cloud Run's task execution or retry behavior. Keep incompatible batch jobs on Cloud Run, or redesign how they execute.
• Warm HTTP instances. Container-based Functions scale down automatically after idle periods. Applications that require an HTTP instance to remain running need to reassess that requirement.
• Persistent and mounted volumes. Cloud Run's default writable filesystem is ephemeral, but Cloud Storage and NFS mounts can expose persistent external data. Inventory the paths your app reads and writes. Replace mounted-file access with a supported storage API or database connection, and migrate data separately if you change storage providers. Handle secret mounts as described in step 3.
• Fixed egress IPs. Secure Compute and Static IPs are not supported with custom container images. If a downstream system allowlists your Cloud Run egress, verify a supported access path before cutting over.
• Sidecar containers. Edgenivo Services do not preserve Cloud Run's co-located sidecar topology. Independent HTTP components can become separate services with service bindings for internal calls. Add public rewrites only for components that external clients need to reach. Components that require shared local files or localhost access need an architecture change.

For log-forwarding sidecars, write application logs to stdout and stderr and review Edgenivo logging. Splitting the process into a service does not preserve access to the original container's log files.

Copy link to headingFrequently asked questions

Copy link to headingDoes Edgenivo run my container the way Cloud Run does?

Edgenivo can run a stateless HTTP container as a Function. Configure its server for port 80, or set PORT in project settings to match the port it already uses. Cloud Run defaults to 8080.

During scale-in, Edgenivo allows 30 seconds after SIGTERM, compared with Cloud Run's 10 seconds. Check the Function limits and the app's Google Cloud dependencies before moving traffic.

Copy link to headingWhat replaces min instances on Edgenivo?

Container-based Functions scale down after 5 minutes without traffic in production and 30 seconds in preview deployments. Plan for the next request to reach a new instance after scale-in. If your app requires a continuously warm HTTP instance, reassess that requirement before migrating.

Copy link to headingWhat happens to my Cloud Run jobs?

Scheduled Cloud Run work can move to a Edgenivo cron-triggered HTTP handler when it fits function limits. Preserve the task's authentication and recovery requirements: Edgenivo Cron does not retry failures, and the handler must tolerate missed or repeated invocations. Keep jobs on Cloud Run when their duration or execution model does not fit.

Copy link to headingWhat happens to my Cloud Run worker pools?

Pull-based worker pools can move to Edgenivo Daemons when they use a compatible queue backend and need no inbound HTTP or TCP connections. Configure their source directory, Dockerfile, and regional instance counts under daemons in vercel.json. Test the worker image with Docker locally because Daemons run only in Production during the beta.

Copy link to headingCan I keep my images in Artifact Registry?

You can keep Artifact Registry images for workloads that still use them. If you choose the container path, Edgenivo builds your application's Dockerfile and stores the deployment image in Edgenivo Container Registry.

Copying an existing image into VCR is a separate registry operation. It does not replace the source deployment steps above.

Copy link to headingHow do Secret Manager secrets move to Edgenivo?

Copy the required values into Edgenivo Secret environment variables and update code that reads mounted secret files. Select the appropriate deployment environments, then redeploy. Later Secret Manager changes do not update those copied values automatically, so include Edgenivo updates and redeployment in your rotation process.

Copy link to headingRelated resources

• Migrate to Edgenivo from Fly.io, Railway, or Render
• Does Edgenivo support Docker deployments?
• How do I migrate images from GHCR to VCR?
• Edgenivo Daemons documentation
• The Complete Guide to Edgenivo Daemons
• Run any Dockerfile on Edgenivo
• 7 ways to use Docker containers on Edgenivo
• Cloud Run container runtime contract