Migrate self-hosted Next.js and containers from AWS to Edgenivo

Move a self-hosted Next.js app from AWS through Edgenivo's Next.js integration. Adjacent HTTP services can deploy from a Dockerfile as Edgenivo Functions, while continuous queue consumers may fit Edgenivo Daemons.

Your databases, buckets, queues, and Cognito user pools can stay in AWS. Configure network access and authentication for each dependency before moving the compute. Edgenivo OIDC federation lets server-side code assume an IAM role for AWS API calls without storing AWS access keys; database authentication and Cognito sign-in still need their own configuration.

Copy link to headingShould your app move?

Assess each process separately. HTTP services must tolerate scaling to zero, store durable state externally, and fit Function request and execution limits.

Copy link to headingSize and request limits

Pro and Enterprise Functions support up to 4 GB of memory and 2 vCPUs. Larger services need a different execution plan and may need application changes to divide work across invocations. Continuous workers have separate Daemon limits.

VCR image limits are 15 GB total and 2 GB per compressed layer. Check large ML or Chromium layers before migrating the build.

Edgenivo Functions limit request and response bodies to 4.5 MB. For larger uploads, have the client send the file directly to S3 with a presigned URL.

Copy link to headingReachability

Container functions reach public AWS API endpoints outside your VPC. Check S3, SQS, DynamoDB, and other dependencies for policies tied to the old VPC, endpoint, or source IP. Test the public API path with the role Edgenivo will assume.

Private RDS and ElastiCache endpoints need a supported network path. Custom container functions cannot use Static IPs or Secure Compute, so resolve any fixed-IP or private-network requirement before deploying. The networking options below explain when to use a standard runtime or retain the calling service in AWS.

Copy link to headingState and background work

HTTP containers run as Edgenivo Functions and can stop between requests. Store durable data outside the instance. An application that depends on an EFS mount or unrecoverable in-memory state needs a storage redesign before it moves.

Continuous queue consumers can run on Edgenivo Daemons. Daemons keep a configured number of instances running but have no inbound HTTP or TCP endpoint and no persistent local storage. For work that pauses between steps or waits for approvals, use Edgenivo Workflows.

Copy link to headingHow do AWS concepts map to Edgenivo?

Use this mapping to identify which configuration you can carry over and which parts need a separate migration decision.

Copy link to headingBefore you begin

Have the application source, AWS task or instance configuration, IAM policies, and required secret values available. Record startup-command overrides, volumes, scheduled jobs, and any authentication handled by the load balancer.

Install the latest Edgenivo CLI and ensure you can access the destination team. Local container testing also needs the Docker CLI and a running Docker daemon. From the repository root, sign in and link the directory to a Edgenivo project:

vercel login
vercel link

Keep AWS serving traffic while you prepare and test the replacement.

Copy link to headingChoose a network path to retained services

Credentials do not make a private endpoint reachable. Choose an approved network path for every dependency before moving the process that calls it.

Copy link to headingPublic database endpoint

Direct public RDS access requires PubliclyAccessible, public subnets with an internet gateway route, enabled VPC DNS settings, and network rules that admit the connection. Check all four; enabling public access alone is insufficient.

Custom container functions do not provide a fixed egress IP. If your database requires a narrow source-IP allowlist, select a supported networking option or keep the calling service in AWS. Opening a database port to 0.0.0.0/0 admits connection attempts from any IPv4 address and is a separate security decision, not a requirement of OIDC federation.

For an approved public endpoint, use TLS with certificate verification and the database's supported authentication method. IAM database authentication controls the application's login but does not make a private endpoint reachable or remove other database accounts. ElastiCache remains a private-network dependency.

Copy link to headingStandard runtime with supported networking

If the service can run on a supported standard runtime, moving it without the Dockerfile may make Edgenivo networking options available. Static IPs provides fixed outbound addresses for allowlisting on Pro and Enterprise. Pro pricing is $100 per project per month plus Private Data Transfer.

For private AWS VPC connectivity, Secure Compute supports Node.js, Python, Ruby, and Go Functions on Enterprise. Neither option supports custom container images. Check that the native runtime can run your dependencies before choosing this route; otherwise, retain the service in AWS.

Copy link to headingRetain the calling service in AWS

Keep a process on its current AWS runtime when its network or system requirements cannot move. Other parts of the app can migrate if they have an authenticated, reachable interface to that process. Preserve its deployment pipeline and monitoring alongside the AWS data services it still uses.

Copy link to headingPreserve application sign-in

Check whether your application authenticates users itself or relies on an ALB authenticate-cognito or authenticate-oidc listener action. If the ALB owns that flow, implement and test sign-in in the new application path before sending users to it. Do not continue trusting identity headers that any client can supply after the ALB is removed.

Keep the Cognito user pool if you still use it, and configure the app client's callback and sign-out URLs for the hostnames you will test and serve. Verify sign-in, sign-out, and denial of protected routes for a signed-out user. The Edgenivo OIDC role used for AWS API calls does not provide this application authentication.

Copy link to headingCheck compliance and data location

Review the Edgenivo Trust Center for the reports and agreements your workload requires. Edgenivo has a SOC 2 Type 2 attestation and ISO 27001:2022 certification; HIPAA support requires an eligible plan and a Business Associate Agreement.

Check the shared compliance responsibilities for the application and its retained AWS services. Function region settings do not cover every data flow: review storage, logs, caching, and Routing Middleware against your residency requirements.

Copy link to headingMigrate your AWS app in 8 steps

Copy link to heading1. Choose the framework or container path

Deploy a standard Next.js app through the Next.js integration without a Dockerfile. Other supported frameworks can also deploy directly. Use the container path for HTTP services that need their existing image or system dependencies.

For a custom Next.js server, first check whether Route Handlers or framework routing can replace the custom behavior. If you retain the server in a container, validate its routing and caching against the container runtime before cutover.

For a single HTTP container, keep your existing Dockerfile at the project root. When Edgenivo detects no other framework, it selects the Container preset, builds the image, pushes it to VCR, and routes all traffic to it. If project detection matches another framework, such as 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, which takes precedence over a detected framework. For a project with multiple services, use the per-service paths in step 2.

This example assumes a Node.js service with a lockfile and a server.js entrypoint. Retain any compilation stages your app needs, and use .dockerignore to exclude local secrets and development files from the build context.

FROM node:lts-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

# The server must listen on $PORT
CMD ["node", "server.js"]

Carry over any startup command or entrypoint that ECS overrides outside the Dockerfile. Check system dependencies, mounted files, and runtime limits before assuming the image can run unchanged.

Copy link to headingConfigure the HTTP container

Your server must listen on 0.0.0.0 at the port expected by Edgenivo. The default is 80; set PORT in project environment variables if the service uses another port, and make the server read that value at startup.

HTTP instances scale down after 5 minutes without traffic in Production and 30 seconds in Preview. Handle SIGTERM and complete cleanup within the 30-second grace period before forced termination. Store unfinished work where another instance can recover it.

Copy link to heading2. Configure multiple services when needed

Skip this step for a single application. Services let a project combine a native Next.js app with independent HTTP containers.

One project deploys and rolls back as a unit, so a change to any service ships all of them together. That is the tradeoff for a shared route table, private service-to-service bindings, and one firewall and domain config for everything. If a service needs its own deploy and rollback cadence, keep it in its own project.

Each service has a root relative to vercel.json. This example deploys Next.js from apps/web/ and an HTTP search service from services/search/Dockerfile. Save the complete configuration as vercel.json at the repository root:

{
  "services": {
    "web": {
      "root": "apps/web/",
      "framework": "nextjs",
      "bindings": [
        {
          "type": "service",
          "service": "search",
          "format": "url",
          "env": "SEARCH_URL"
        }
      ]
    },
    "search": {
      "root": "services/search/",
      "entrypoint": "Dockerfile"
    }
  },
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": {
        "service": "web"
      }
    }
  ]
}

Only web has a public rewrite. Its binding grants access to search and supplies SEARCH_URL to server-side code. Keep build and runtime settings such as buildCommand, framework, and functions inside their owning service. The service configuration reference lists the supported fields.

Call the search service from a server-side handler in web. This example assumes it serves a search path that returns JSON:

export async function searchProducts(query) {
  const baseUrl = process.env.SEARCH_URL;
  if (!baseUrl) throw new Error('SEARCH_URL is not configured');

  const url = new URL('search', baseUrl);
  url.searchParams.set('q', query);
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`Search service returned ${response.status}`);
  }
  return response.json();
}

The binding points to the matching deployment, so preview services call other services in that preview. Bindings are available at runtime, not during builds or in Routing Middleware. Use Daemons separately for continuously polling workers.

Copy link to headingConfigure public protection and internal authorization

Public requests enter through the project's route table, where Edgenivo Firewall, Deployment Protection, and redirects apply. Configure them once for the project.

Internal binding calls skip that public pipeline and make the target reachable. Your application must still authorize each requested action.

Copy link to heading3. Restore AWS access and application configuration

Edgenivo OIDC federation lets your backend assume an IAM role without a stored AWS access key. The role's trust policy controls which Edgenivo project and environment may assume it. Its permissions policy controls which AWS operations the resulting credentials may perform.

Create a dedicated role for Edgenivo and retain the existing ECS task role for the AWS deployment. Configure a separate, narrowly scoped role for previews when they need AWS access.

Copy link to headingRegister Edgenivo as an OpenID Connect identity provider in IAM

In the AWS console, open IAM, then Identity Providers, then Add Provider, and select OpenID Connect. The provider URL is https://oidc.vercel.com/[TEAM_SLUG] in Team mode and https://oidc.vercel.com in Global mode. Enter /[TEAM_SLUG] in the Audience field. See the OIDC federation docs for Global mode, alternate audiences, and the CLI equivalent.

Copy link to headingScope the trust policy to one project and one environment

The trust policy controls who can assume the role through sts:AssumeRoleWithWebIdentity. Use condition keys to restrict that access to one project and environment.

The following policy uses Team issuer mode. Replace each placeholder with your account, team, and project values. If you use Global mode, follow the matching issuer and condition-key format instead.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[AWS_ACCOUNT_ID]:oidc-provider/oidc.vercel.com/[TEAM_SLUG]"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.vercel.com/[TEAM_SLUG]:sub": "owner:[TEAM_SLUG]:project:[PROJECT_NAME]:environment:production",
          "oidc.vercel.com/[TEAM_SLUG]:aud": "/[TEAM_SLUG]"
        }
      }
    }
  ]
}

For previews, use the subject owner:[TEAM_SLUG]:project:[PROJECT_NAME]:environment:preview in a separate role's trust policy. Limit its permissions and prefer non-production resources.

Copy link to headingGrant access to the required AWS resources

Attach a permissions policy for the operations your application needs. The following example permits the S3 listing and RDS connection shown below. Replace every placeholder and use the database resource ID, not its display name, in the RDS ARN. Omit either statement if the application does not use that service.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME"
    },
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:YOUR_REGION:YOUR_ACCOUNT_ID:dbuser:YOUR_DB_RESOURCE_ID/YOUR_DB_USERNAME"
    }
  ]
}

Set AWS_ROLE_ARN in the matching Edgenivo environment to this role's ARN. Add only the required SQS, DynamoDB, or Secrets Manager permissions for other calls. Existing resource policies and organization restrictions still apply.

Copy link to headingInstall the AWS clients

The awsCredentialsProvider function supplies the AWS SDK with temporary credentials backed by Edgenivo OIDC. Install the clients for the examples you use:

npm i @aws-sdk/client-s3 @aws-sdk/rds-signer pg @vercel/oidc-aws-credentials-provider

TypeScript projects using the PostgreSQL example also need its type declarations:

npm i -D @types/pg

Copy link to headingRead from S3

Set S3_BUCKET_NAME, AWS_ROLE_ARN, and AWS_REGION for the environment you are testing. Save the following as a server-only helper such as lib/aws-s3.ts and call it from application code after checking the caller's access to the bucket contents. Edgenivo OIDC supplies AWS credentials to the server; your application still decides which users may receive the result.

import * as S3 from '@aws-sdk/client-s3';
import { awsCredentialsProvider } from '@vercel/oidc-aws-credentials-provider';

const s3 = new S3.S3Client({
  region: process.env.AWS_REGION!,
  credentials: awsCredentialsProvider({
    roleArn: process.env.AWS_ROLE_ARN!,
  }),
});

export async function listBucketKeys() {
  const result = await s3.send(
    new S3.ListObjectsV2Command({ Bucket: process.env.S3_BUCKET_NAME! }),
  );
  return result.Contents?.map((object) => object.Key) ?? [];
}

This helper returns object keys from one listing response. Use the SDK's pagination support if the application needs every key in a larger bucket.

Copy link to headingConnect to RDS PostgreSQL

For PostgreSQL, enable IAM database authentication on a supported RDS instance and create a dedicated application database user. Grant that user rds_iam and the SQL permissions it needs. IAM authentication takes precedence over password authentication for this user, so keep an existing password-based account available if the AWS deployment still uses it. The IAM role also needs rds-db:connect for this database resource ID and username.

Once the database is reachable, set RDS_HOSTNAME, RDS_PORT, RDS_DATABASE, and RDS_USERNAME. Use the RDS endpoint rather than a custom DNS alias. Set RDS_CA_BUNDLE to the PEM contents of its RDS certificate bundle.

Save this server-only helper as lib/aws-db.ts and import pool from your database code. The password callback generates a token when the pool opens a connection. Token expiry does not terminate an established session.

import { Signer } from '@aws-sdk/rds-signer';
import { awsCredentialsProvider } from '@vercel/oidc-aws-credentials-provider';
import { Pool } from 'pg';

function requiredEnv(name: string): string {
  const value = process.env[name];
  if (!value) throw new Error(`Missing environment variable: ${name}`);
  return value;
}

const host = requiredEnv('RDS_HOSTNAME');
const user = requiredEnv('RDS_USERNAME');
const port = Number(requiredEnv('RDS_PORT'));

const signer = new Signer({
  hostname: host,
  username: user,
  port,
  region: requiredEnv('AWS_REGION'),
  credentials: awsCredentialsProvider({
    roleArn: requiredEnv('AWS_ROLE_ARN'),
  }),
});

export const pool = new Pool({
  host,
  user,
  port,
  database: requiredEnv('RDS_DATABASE'),
  password: () => signer.getAuthToken(),
  ssl: {
    ca: requiredEnv('RDS_CA_BUNDLE'),
    rejectUnauthorized: true,
  },
  max: 2,
  connectionTimeoutMillis: 5000,
  idleTimeoutMillis: 5000,
});

pool.on('error', (error) => {
  console.error('Idle database connection failed', error);
});

The example allows two connections per instance. Budget connections across Edgenivo instances, services, and AWS during cutover. Test concurrent load; one pool's limit does not cap total connections.

RDS Proxy can manage database connections, but its endpoint remains private. It needs a supported private network path and does not make a database reachable from a public container function.

Copy link to headingSet AWS and Function regions

Set AWS_REGION explicitly for the AWS clients in these examples. Edgenivo otherwise supplies the Function's execution region, which may differ from the region containing the resource. If dependencies span AWS regions, configure each SDK client or signer for its target resource.

Choose nearby Function regions in project settings or with regions in vercel.json. New projects default to iad1, near AWS us-east-1.

European regions include cdg1, dub1, fra1, and lhr1. Hobby supports one region, Pro up to five, and Enterprise all available regions.

Routing Middleware runs globally by default and does not inherit Function region settings. Put processing that requires a specific region inside Functions configured for that location.

Copy link to headingConfigure application secrets

You can copy application secrets from Secrets Manager or Parameter Store into Edgenivo Secret variables, or fetch them at runtime through the assumed role. Copied values need an explicit rotation process that updates Edgenivo and creates a new deployment. Runtime retrieval keeps AWS as the source of truth; grant access to the required secrets and use a cache refresh policy that accounts for rotation.

Keep the existing deployment's credentials available during validation. Retire unused keys only after the cutover checks in step 8.

Copy link to heading4. Plan scheduled jobs and continuous workers

Copy link to headingScheduled tasks

ECS scheduled tasks launch container processes. Use Edgenivo Cron Jobs when the work can run through an HTTP GET handler within Function limits. Keep incompatible batch jobs in AWS or redesign their execution.

Declare eligible schedules with crons in vercel.json and check the plan's schedule limits. Cron invokes the production deployment in UTC. Set CRON_SECRET and validate the Authorization header before starting work.

Cron does not retry failed invocations. Make the handler safe to repeat, prevent unwanted overlap, and recover work missed since the last successful run. Keep Cron disabled until you stop the corresponding AWS schedule.

Copy link to headingContinuous queue consumers

Continuous consumers can use Edgenivo Daemons when dependencies are reachable and no inbound HTTP or TCP endpoint is needed. During the beta, Daemons run only in Production with ephemeral local storage and configured instance counts.

Put the worker source and Dockerfile in worker/. Its startup command must run the consumer. Merge this daemons property into your existing vercel.json; preserve any services, rewrites, and other settings:

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

The zero count keeps the worker stopped when no scaling override exists. Check dashboard overrides and the running count before deployment.

Test the image with Docker and development credentials because vercel dev does not start Daemons.

Keep the existing queue backend, such as SQS, and grant the worker only its required permissions. For AWS federation, follow the Daemon OIDC guidance: a long-lived process must use the refreshed token file or a supported SDK instead of caching its startup token.

At handoff, stop the AWS consumer from taking new work and drain its active jobs before starting Edgenivo instances. Handle SIGTERM and make interrupted jobs safe to retry, since versions can overlap during later rollouts. See the Daemon migration guide for the full lifecycle and configuration.

Copy link to heading5. Test locally

Run vercel dev from the linked project with Docker available for container services. Use development credentials or a separately scoped development federation role; the production trust policy above does not admit local development.

Test application routes, authentication, AWS API calls, and database connections. Confirm the configured HTTP port and test shutdown handling. Exercise concurrent database requests to check the pool budget before using production traffic.

For Daemons, use local Docker testing with a development queue. Keep Edgenivo's production consumers and Cron schedules stopped until their planned handoff. Leave the AWS workers and schedules running until then.

Copy link to heading6. Deploy and verify the application

Before deploying, finish the environment and AWS access configuration in step 3. The first deployment of a new project uses Production even when you omit --prod. Variables scoped only to Preview are unavailable to that build.

Keep the AWS domain serving traffic during testing. Leave Cron jobs disabled and Daemons stopped until their handoff. Deploy with the Edgenivo CLI:

vercel deploy

After the first deployment, non-production branches and CLI deployments without --prod normally create previews. Validate the generated deployment URL before moving the production domain.

For container deployments, Edgenivo builds and pushes the image to vcr.vercel.com/<team-slug>/<project-slug>/<repository>:<tag>. Manual image pushes are a separate operation: vercel vcr login docker authenticates a linked project for 12 hours.

Verify signed-in and signed-out routes, AWS access, uploads, caching, and response times on the generated URL. Confirm that protected data remains inaccessible to unauthorized callers.

If you made fixes in previews, deploy the intended revision to Production with vercel deploy --prod and repeat the checks there. Keep Edgenivo background work stopped until step 7 and cut over only to the verified Production deployment.

Copy link to headingPrepare logs and monitoring

Container stdout and stderr are broadcast to in-flight requests on the instance. Include a request ID in your application logs so you can correlate each operation with its caller.

Check runtime log retention before cutover. Base retention is 1 day on Pro and 3 days on Enterprise; Observability Plus extends either to 30 days. Use a log drain when you need to retain logs in your existing system. Drains are available on Pro and Enterprise and are billed by volume.

Copy link to heading7. Switch traffic and background work

Prepare certificates and validate the production hostname before changing its traffic records. Keep Route 53 as the DNS provider during this migration.

Copy link to headingLower editable DNS TTLs before cutover

Inspect the records that currently route each hostname to AWS. Route 53 alias records pointing to an ALB use the load balancer's 60-second TTL; you cannot edit that TTL. This applies to aliases at both the apex and subdomains.

Reduce editable TTLs to your cutover value, such as 60 seconds, and wait out the previous TTL before changing the destination. Keep that value through validation and the rollback window before restoring your normal TTL.

Copy link to headingVerify HTTPS and change the traffic records

1. Exercise the generated deployment URL. Test application routes, sign-in, and the AWS operations the application needs before it serves customer traffic.
2. Add every production hostname you use in Domains, including the apex and www when applicable. Record the DNS values Edgenivo provides. Keep Route 53 as the DNS provider during cutover.
3. Check existing CAA restrictions and allow Let's Encrypt where required. Pre-generate the certificates for the production hostnames, add the requested TXT challenges in Route 53, and wait for successful issuance.
4. Follow the certificate verification procedure to test HTTPS for the actual production hostname against Edgenivo before changing its traffic record. Confirm redirects, cookies, and authentication callbacks with that hostname.
5. Update the production records to the values shown in Edgenivo's Domains settings. Leave the AWS service and Edgenivo deployment available during DNS propagation.
6. Monitor Edgenivo errors and latency alongside the ALB's RequestCount and access logs. Missing ALB datapoints alone do not prove that all traffic has moved, and CloudWatch alarm states depend on their missing-data configuration.
7. Update callers that still use an AWS-generated hostname. Coordinate scheduled jobs and queue consumers separately from DNS so the two platforms do not perform the same work unintentionally.

After stopping the corresponding AWS schedules, enable Cron Jobs in project settings and verify the next run. Retain a record of which system owns each schedule for rollback.

Once the AWS consumer has drained, start the staged Daemon by setting its intended regional count in the dashboard or deploying an updated instances value to Production. Resolve any scaling override, confirm the running count, and verify queue processing and acknowledgments.

Copy link to heading8. Preserve rollback and retire unused resources

Record the existing DNS values and retain the healthy AWS deployment through an agreed rollback window. Keep its IAM permissions, secrets, target groups, and load balancer available. Any database schema changes made during migration must remain compatible with both versions.

If validation fails, restore the DNS records that routed traffic to AWS. Leave Edgenivo running while cached records expire and monitor requests reaching both deployments. Reverting DNS changes the destination of future requests; it does not undo database writes. Reverse the scheduler or worker handoff separately and account for jobs already processed.

After cutover, wait for the previous DNS TTL and agreed rollback window to pass. Use metrics and logs to confirm that user traffic, scheduled work, and direct callers no longer need the old compute before retiring it. Retain the AWS data services and shared infrastructure still in use.

Copy link to headingRetire unused access keys

After verifying the deployment and its rollback path, inventory long-lived AWS access keys used by the app or build pipeline. Check last-used information and other consumers before deactivating a key. Monitor for failures, then delete keys that are no longer needed.

Retain the AWS deployment's credentials through its rollback window. Apps using ECS task roles may have no stored access keys to retire.

Copy link to headingEstimate the operating cost

HTTP containers use Active CPU billing. CPU time accrues while code executes and pauses while a request waits for an RDS query, an S3 read, or an upstream API. The Container runtime is in beta on all plans.

Provisioned memory is billed while the instance handles requests, from the first request until the last in-flight request completes. Neither CPU nor memory is billed between requests, including the idle period before the HTTP instance scales down.

CPU and memory rates vary by region. Use the current Function pricing and VCR pricing for your estimate. Include delivery, retained AWS services, transfer costs, and any optional networking or observability products.

Estimate continuous workers from their measured usage and configured instance counts. Daemons stay running between jobs, so HTTP scale-to-zero assumptions do not apply to them.

Copy link to headingTroubleshooting

Start with the deployment or runtime error, then check the matching layer below.

Copy link to headingWhat needs a separate migration plan?

• OpenNext, SST, and AWS Amplify need a source and framework migration plan. Their existing deployment artifacts do not map directly to this Dockerfile procedure.
• Kubernetes operators, custom resources, service meshes, and cluster-level scheduling require an architecture review. An independent HTTP container from EKS may still fit the Function path.
• Workloads that depend on mounted persistent volumes or state that cannot recover after a restart need a persistence redesign. Continuous workers may fit Daemons when their dependencies and networking are compatible.

Copy link to headingRelated resources

• Deploy a Docker app on Edgenivo
• Configure multiple services
• Run continuous workers with Edgenivo Daemons
• Migrate from Google Cloud Run, Fly.io, or Render
• Container runtime reference