Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion src/content/docs/containers/examples/cron.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,6 @@ import { Container, getContainer } from "@cloudflare/containers";

export class CronContainer extends Container {
sleepAfter = "5m";
manualStart = true;
}

export default {
Expand Down
70 changes: 18 additions & 52 deletions src/content/docs/containers/examples/env-vars-and-secrets.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,47 +13,22 @@ import { WranglerConfig, PackageManagers } from "~/components";
Environment variables can be passed into a Container using the `envVars` field
in the `Container` class, or by setting manually when the Container starts.

Secrets can be passed into a Container by using [Worker Secrets](/workers/configuration/secrets/)
or the [Secret Store](/secrets-store/integrations/workers/), then passing them into the Container
as environment variables.
Secrets can be passed into a Container by using [Worker Secrets](/workers/configuration/secrets/),
then passing them into the Container as environment variables.

These examples show the various ways to pass in secrets and environment variables. In each, we will
be passing in:

- the variable `"ACCOUNT_NAME"` as a hard-coded environment variable
- the secret `"CONTAINER_SECRET_KEY"` as a secret from Worker Secrets
- the secret `"ACCOUNT_API_KEY"` as a secret from the Secret Store

In practice, you may just use one of the methods for storing secrets, but
we will show both for completeness.
- the secret `"ACCOUNT_API_KEY"` as a secret from Worker Secrets

## Creating secrets

First, let's create the `"CONTAINER_SECRET_KEY"` secret in Worker Secrets:

<PackageManagers
type="exec"
pkg="wrangler"
args="secret put CONTAINER_SECRET_KEY"
/>

Then, let's create a store called "demo" in the Secret Store, and add
the `"ACCOUNT_API_KEY"` secret to it:

<PackageManagers
type="exec"
pkg="wrangler"
args="secrets-store store create demo --remote"
/>
First, let's create the `"ACCOUNT_API_KEY"` secret in Worker Secrets:

<PackageManagers
type="exec"
pkg="wrangler"
args="secrets-store secret create demo --name ACCOUNT_API_KEY --scopes workers --remote"
/>
<PackageManagers type="exec" pkg="wrangler" args="secret put ACCOUNT_API_KEY" />

For full details on how to create secrets, see the [Workers Secrets documentation](/workers/configuration/secrets/)
and the [Secret Store documentation](/secrets-store/integrations/workers/).
For full details on how to create secrets, see the [Workers Secrets documentation](/workers/configuration/secrets/).

## Adding a secrets binding

Expand All @@ -66,15 +41,8 @@ in Wrangler configuration.
{
"name": "my-container-worker",
"vars": {
"ACCOUNT_NAME": "my-account"
},
"secrets_store_secrets": [
{
"binding": "SECRET_STORE",
"store_id": "demo",
"secret_name": "ACCOUNT_API_KEY"
}
]
"ACCOUNT_API_KEY": "abcdef12345"
}
// rest of the configuration...
}
```
Expand All @@ -92,13 +60,14 @@ or secrets in the container-related portion of wrangler configuration.
Now, let's define a Container using the `envVars` field in the `Container` class:

```js
import { env } from "cloudflare:workers";

export class MyContainer extends Container {
defaultPort = 8080;
sleepAfter = '10s';
envVars = {
ACCOUNT_NAME: env.ACCOUNT_NAME,
ACCOUNT_API_KEY: env.SECRET_STORE.ACCOUNT_API_KEY,
CONTAINER_SECRET_KEY: env.CONTAINER_SECRET_KEY,
defaultPort = 8080;
sleepAfter = "10s";
envVars = {
ACCOUNT_NAME: env.ACCOUNT_NAME,
ACCOUNT_API_KEY: env.ACCOUNT_API_KEY,
};
}
```
Expand All @@ -110,14 +79,13 @@ set as environment variables when it launches.

But what if you want to set environment variables on a per-instance basis?

In this case, set `manualStart` then use the `start` method to pass in environment variables for each instance.
In this case, use the `start` method to pass in environment variables for each instance.
We'll assume that we've set additional secrets in the Secret Store.

```js
export class MyContainer extends Container {
defaultPort = 8080;
sleepAfter = '10s';
manualStart = true;
}

export default {
Expand All @@ -134,16 +102,14 @@ export default {
await instanceOne.start({
envVars: {
ACCOUNT_NAME: env.ACCOUNT_NAME + "-1",
ACCOUNT_API_KEY: env.SECRET_STORE.ACCOUNT_API_KEY_ONE,
CONTAINER_SECRET_KEY: env.CONTAINER_SECRET_KEY_TWO,
ACCOUNT_API_KEY: env.ACCOUNT_API_KEY_ONE,
}
)

await instanceTwo.start({
envVars: {
ACCOUNT_NAME: env.ACCOUNT_NAME + "-2",
ACCOUNT_API_KEY: env.SECRET_STORE.ACCOUNT_API_KEY_TWO,
CONTAINER_SECRET_KEY: env.CONTAINER_SECRET_KEY_TWO,
ACCOUNT_API_KEY: env.ACCOUNT_API_KEY_TWO,
}
)
return new Response('Container instances launched');
Expand Down
8 changes: 6 additions & 2 deletions src/content/docs/containers/faq.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -135,20 +135,24 @@ to define secrets for your Workers.
Then you can pass these secrets to your Container using the `envVars` property:

```javascript
import { env } from "cloudflare:workers";

class MyContainer extends Container {
defaultPort = 5000;
envVars = {
MY_SECRET: this.env.MY_SECRET,
MY_SECRET: env.MY_SECRET,
Comment on lines -141 to +143
Copy link

@anthonywu anthonywu Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs stay this.env as this refers to Container and this.env is inherited Container.env

it is env.MY_SECRET pattern that's throwing this on the dev tail:

✘ [ERROR] Uncaught ReferenceError: env is not defined

When I put this back to this.env in the Container envVars, it works again.

};
}
```

Or when starting a Container instance on a Durable Object:

```javascript
import { env } from "cloudflare:workers";

this.ctx.container.start({
env: {
MY_SECRET: this.env.MY_SECRET,
MY_SECRET: env.MY_SECRET,
},
});
```
Expand Down
6 changes: 3 additions & 3 deletions src/content/docs/containers/local-dev.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,9 @@ the `image` attribute to a local path, the image will be built using the local D
If the `image` attribute is set to a URL, the image will be pulled from the associated registry.

Container instances will be launched locally when your Worker code calls to create
a new container. This may happen when calling `.get()` on a `Container` instance or
by calling `start()` if `manualStart` is set to `true`. Wrangler will
boot new instances and automatically route requests to the correct local container.
a new container. This may happen when calling `.fetch()`, `.containerFetch()` or `start()`
on a `Container` instance. Wrangler will boot new instances and automatically route
requests to the correct local container.

When `wrangler dev` stops, all associated container instances are stopped, but
local images are not removed, so that they can be reused in subsequent calls to
Expand Down
4 changes: 2 additions & 2 deletions src/content/docs/containers/scaling-and-routing.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ sidebar:
### Scaling container instances with `get()`

Currently, Containers are only scaled manually by calling `BINDING.get()` with a unique ID, then
starting the container. Unless `manualStart` is set to `true` on the Container class, each
instance will start when `get()` is called.
starting the container. Each instance will start when the first request is made to it with `fetch()` or
when manually started with `start()`.

```
// gets 3 container instances
Expand Down