Frequently Asked Questions
Frequently Asked Questions:
To get logs in the Dashboard, including live tailing of logs, toggle observability
to true
in your Worker's wrangler config:
{ "observability": { "enabled": true }}
[observability]enabled = true
Logs are subject to the same limits as Worker logs, which means that they are retained for 3 days on Free plans and 7 days on Paid plans.
See Workers Logs Pricing for details on cost.
If you are an Enterprise user, you are able to export container logs via Logpush to your preferred destination.
When initially deploying a Container, Cloudflare will select various locations across our network to deploy instances to. These locations will span multiple regions.
When a Container instance is requested with this.ctx.container.start
, the nearest free
container instance will be selected from the pre-initialized locations. This will
likely be in the same region as the external request, but may not be. Once the container
instance is running, any future requests will be routed to the initial location.
An Example:
- A user deploys a Container. Cloudflare automatically readies instances across its Network.
- A request is made from a client in Bariloche, Argentia. It reaches the Worker in Cloudflare's location in Neuquen, Argentina.
- This Worker request calls
MY_CONTAINER.get("session-1337")
which brings up a Durable Object, which then callsthis.ctx.container.start
. - This requests the nearest free Container instance.
- Cloudflare recognizes that an instance is free in Buenos Aires, Argentina, and starts it there.
- A different user needs to route to the same container. This user's request reaches the Worker running in Cloudflare's location in San Diego.
- The Worker again calls
MY_CONTAINER.get("session-1337")
. - If the initial container instance is still running, the request is routed to the location in Buenos Aires. If the initial container has gone to sleep, Cloudflare will once again try to find the nearest "free" instance of the Container, likely one in North America, and start an instance there.
When you run wrangler deploy
, the Worker code is updated immediately and Container
instances are updated using a rolling deploy strategy. Container instances are updated
in batches, with 25% of instances being updated at a time by default.
When a Container instance is ready to be stopped, it is sent a SIGTERM
signal, which
allows it to gracefully shut down. If the instance does not stop within 15 minutes,
it is forcefully stopped with a SIGKILL
signal. If you have cleanup that must occur
before a Container instance is stopped, you should do it during this period.
Once stopped, the instance is replaced with a new instance running the updated code. When the new instance starts, requests will hang during container startup.
See scaling & routing documentation for details.
A cold start is when a container instance is started from a completely stopped state.
If you call env.MY_CONTAINER.get(id)
with a completely novel ID and launch
this instance for the first time, it will result in a cold start.
This will start the container image from its entrypoint for the first time. Depending on what this entrypoint does, it will take a variable amount of time to start.
Container cold starts can often be the 2-3 second range, but this is dependent on image size and code execution time, among other factors.
See image management documentation for details.
All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image.
Persistent disk is something the Cloudflare team is exploring in the future, but is not slated for the near term.
If you run out of memory, your instance will throw an Out of Memory (OOM) error and will be restarted.
Containers do not use swap memory.
Cloudflare will not actively shut off a container instance after a specific amount of
time. If you do not set sleepAfter
on your Container class, or stop the instance
manually, it will continue to run unless its host server is restarted. This
happens on an irregular cadence, but frequently enough where Cloudflare does not
guarantee that any instance will run for any set period of time.
When a container instance is going to be shut down, it is sent a SIGTERM
signal,
and then a SIGKILL
signal after 15 minutes. You should perform any necessary
cleanup to ensure a graceful shutdown in this time. The container instance
will be rebooted elsewhere shortly after this.
You can use Worker Secrets or the Secrets Store to define secrets for your Workers.
Then you can pass these secrets to your Container using the envVars
property:
class MyContainer extends Container { defaultPort = 5000; envVars = { MY_SECRET: this.env.MY_SECRET, };}
Or when starting a Container instance on a Durable Object:
this.ctx.container.start({ env: { MY_SECRET: this.env.MY_SECRET, },});
See the Env Vars and Secrets Example for details.
When booting a Container, you can specify enableInternet
, which will toggle
internet access on or off.
To disable it, configure it on your Container class:
class MyContainer extends Container { defaultPort = 7000; enableInternet = false;}
or when starting a Container instance on a Durable Object:
this.ctx.container.start({ enableInternet: false,});
Was this helpful?
- Resources
- API
- New to Cloudflare?
- Products
- Sponsorships
- Open Source
- Support
- Help Center
- System Status
- Compliance
- GDPR
- Company
- cloudflare.com
- Our team
- Careers
- 2025 Cloudflare, Inc.
- Privacy Policy
- Terms of Use
- Report Security Issues
- Trademark
-