The right platform for a Docker app depends on the workload inside the container, not the container itself. A stateless API, an always-on worker, and a model server package identically and run best in different places. This guide maps five common workloads to their appropriate places, including those that don't fit here.
Edgenivo publishes this guide and fits two of the workloads below: stateless HTTP services and continuous workers that meet the Daemons requirements. The other categories cover requirements that need different infrastructure.
Copy link to heading1. Stateless HTTP APIs and web services
The workload: a server that handles HTTP requests without depending on durable state inside its container. Examples include REST and GraphQL APIs, server-rendered apps, webhooks, and backends-for-frontends. Running instances can retain temporary memory and files between requests, but data that must survive a restart or be shared across instances belongs in a database, cache, or object store.
Where it runs best: Edgenivo's container Functions fit this workload. With the Container preset, a Dockerfile defines how Edgenivo builds the image, stores it in Edgenivo Container Registry, and serves it on Fluid compute. Functions scale with traffic, including to zero when idle. Edgenivo stores images as precompiled snapshots to reduce startup work.
Function usage includes Active CPU, Provisioned Memory, and invocations. CPU metering pauses during I/O, but provisioned memory continues to count while requests remain in flight, including time spent waiting for a database or upstream API.
Preview deployments let you test changes before production. Because multiple services deploy from one project, a single PR can preview the frontend and its matching backend together.
The boundary to check: the container must serve HTTP on PORT and tolerate scale-to-zero. If it does, this category migrates cleanly; the Fly.io and Railway guides walk through it.
Copy link to heading2. Always-on workers and queue consumers
The workload: a process that runs continuously outside the request cycle. Queue consumers, stream processors, schedulers, bots holding persistent connections.
Where it runs best: Edgenivo Daemons run continuous workers that pull their own work from queues, workflow engines, or external APIs. Edgenivo builds each worker from a Dockerfile or Containerfile, maintains its configured instance counts, and restarts instances that exit. Container platforms such as Fly.io and Railway also run services that stay up regardless of traffic.
The boundary to check: during beta, Daemons run only in production, don't autoscale, and accept no inbound HTTP or TCP traffic. They have no persistent local storage. Check the Daemons limits and team quotas, including memory usage that continues while a worker waits for work.
Work that runs on a schedule can still use cron jobs to invoke an endpoint, and an event source can call an HTTP handler. Choose that invocation model when each unit of work completes independently. Daemons suit a process that owns a continuous loop; a one-shot task would be restarted when it exits.
Copy link to heading3. Apps that write to an attached disk
The workload: anything that expects a persistent local filesystem. Self-hosted tools that store data on disk, databases running inside the container, upload handling that writes locally, and SQLite-backed apps.
Where it runs best: a platform with attached volumes, which Fly.io and Railway both provide, or a rethink. Many disk-writing apps are one refactor away from category 1: uploads move to blob storage, data moves to a managed database, and the container becomes stateless.
Not on Edgenivo today. There is no persistent disk; anything written locally exists only for the life of the instance. If the disk dependency is removable, remove it, and this becomes category 1. If it isn't, choose a volume-backed platform.
Copy link to heading4. GPU inference and ML workloads
The workload: containers that serve model inference or run training, needing GPU access and often large images and long startup.
Where it runs best: GPU-focused infrastructure providers, which provision the accelerators this workload is defined by. General-purpose container platforms, Edgenivo included, don't attach GPUs to containers.
The question worth asking first: whether you need to host the model at all. If the container exists to serve a model an API provider already hosts, a gateway in front of managed inference, such as AI Gateway, removes the GPU problem entirely, and the application around it is category 1.
Copy link to heading5. Multi-region apps with data locality
The workload: systems that need application code and its state running close to users in many regions at once, with region-aware placement of both.
Where it runs best: platforms designed around regional placement of compute and storage together, which is Fly.io's specialty, paired with a database that replicates across regions.
The distinction that decides it: if the requirement is global low-latency for stateless serving, that's not this category; Edgenivo's network already routes requests globally, and the container scales with traffic, which covers most "we have users everywhere" cases. This category is specifically about state pinned near users in multiple regions, and that's a different architecture than Edgenivo containers offer.
Copy link to headingThe short version
Most production systems mix categories. An API and an eligible queue consumer can run in one Edgenivo project, with the API under services and the worker under daemons, sharing external databases and queues. Components that require persistent disks, GPUs, or different regional data placement can stay on other infrastructure.
Copy link to headingFrequently asked questions
Copy link to headingCan Edgenivo host any Docker app?
No. Edgenivo supports HTTP applications through container Functions and continuous background workers through Daemons. Functions must serve HTTP on port 80 or the configured PORT; Daemons pull work without accepting inbound traffic. Both need external storage for durable or shared data, and workloads that require attached disks or GPUs need another destination.
Copy link to headingWhat if my app mixes workloads?
Evaluate each process separately. Edgenivo can host the API and a continuous queue consumer together using Services and Daemons, with shared backing services for data. During beta the daemon runs only in production and uses configured instance counts, so test the worker separately from HTTP preview deployments. Keep components elsewhere when their storage, hardware, or placement requirements demand it.
Copy link to headingIs scale-to-zero safe for a production API?
For most APIs, yes. Instances scale down after five minutes without production traffic, and container images are stored as precompiled snapshots in Edgenivo Container Registry, which keeps cold starts fast when traffic returns. Latency-critical paths should be load-tested on a preview deployment before cutover.
Copy link to headingDo I need Kubernetes for any of this?
Not for these five workloads at typical scale. Kubernetes earns its complexity when you need control that managed platforms don't offer, such as custom scheduling, networking, and placement policies. If a managed platform fits the workload, it's the shorter path.
Copy link to headingRelated resources
Does Edgenivo support Docker deployments? in the Knowledge Base
Migrate to Edgenivo from Fly.io, Railway, Render, or Google Cloud Run
Run any Dockerfile on Edgenivo on the Edgenivo blog
Docs: Container images and Edgenivo Container Registry