Always-on containers vs serverless functions

When an AI coding agent builds an app, the hosting model decides how the app behaves in production. Two models cover most cases. A serverless function runs your code when a request arrives. An always-on container runs your code all the time. This article compares them on the points that matter to a small app, and says how xhostd runs apps.

The comparison is about models, not products. Platforms differ in their limits, so read a platform's own documentation before you rely on a number.

The two models

A serverless function is a piece of code that a platform starts on demand and stops when the work is done. You do not manage a server, and you are usually billed for what runs.

An always-on container is a process that starts once and keeps running. It holds memory between requests, and it can do work with nobody visiting. You choose a size, and the size sets the price.

Start-up time

A function that has been idle might need to start before it answers, which adds delay to the first request. Platforms describe this as a cold start, and many document ways to limit it.

A container that is always on has no such delay, because the process is already running. It answers the first request as quickly as the hundredth.

Long connections and background work

Many serverless platforms limit how long one invocation can run. That fits a short request and a quick response. It fits poorly with a chat bot that holds a connection open, a worker that polls a queue, or a loop that checks a data source every minute.

A container has no such limit by design. A background worker is an ordinary process that never exits, and a WebSocket connection stays open for as long as the client wants it.

State and databases

A function keeps nothing in memory that you can rely on, so it needs an external store for every piece of state. The database is a separate service, and a busy set of functions can open many connections to it at once.

A container can keep a cache in memory. It still needs a database for anything that must survive a restart, because a redeploy replaces the container and its local disk. Whichever model you use, keep durable state in a database or in object storage.

How the cost behaves

Functions are billed by use. A quiet app costs little, and a busy one costs more. That shape suits spiky, low-volume work, and it makes the bill depend on traffic.

A container is billed by size. The price is the same on a quiet day and on a busy one, until the app outgrows the size and you move up.

When each one fits

Serverless functions fit short, stateless requests with irregular traffic, such as a webhook receiver or a form handler that runs a few times a day.

Always-on containers fit apps that hold connections, run in the background, keep a cache, or need a steady, predictable price. Bots, data tools, dashboards, and most apps an agent builds with a database belong here.

How xhostd runs apps

xhostd runs every channel as an always-on container, on every plan. There is no sleep mode, no scale-to-zero, and no cold start. A preview link that a reviewer opens days later is still running.

• Workers. A background worker runs a loop and serves no web page. The worker recipe shows the pattern.
• A database of its own. Each channel that runs code has its own Postgres database, and a static site has none. See Preview and staging environments on xhostd.
• A price that follows resources. A plan sets your CPU, memory, and storage for a fixed monthly price, and it does not depend on the number of users or the traffic. See the pricing page.

Because xhostd is not a function platform, code that depends on a provider's function interface needs a small wrapper to run as an ordinary web server. An AI coding agent can write that wrapper. To compare a container with a whole server that you manage yourself, read VPS vs. managed hosting: xhostd compared.