No, it is just a function which is supposed to run on its own when container starts, it is a cron co

No, it is just a function which is supposed to run on its own when container starts, it is a cron container, so it does not respond back anything,

import { Container, getContainer } from "@cloudflare/containers";

export class dummy extends Container {
  constructor(state, env) {
    super(state, env);
    // Set envVars in constructor
    this.envVars = {
      NAME: env.name,
    };
  }
  sleepAfter = "30m";
  async onStart() {
    console.log("Container started");
  }
  enableInternet = true;
  onStop() {
    console.log("Container shut down");
  }
  onError(error) {
    console.log("Error:", error);
  }

}
export default {
  async fetch(request, env, ctx) {
    // Trigger Durable Object
    console.log("Manual trigger → starting container");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          // You can pass dynamic values here
          MANUAL_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
    return new Response("Container manually triggered and executed", {
      status: 200,
    });
  },
  async scheduled(controller, env, ctx) {
    console.log("Cron triggered");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          CRON_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
  },
};

import { Container, getContainer } from "@cloudflare/containers";

export class dummy extends Container {
  constructor(state, env) {
    super(state, env);
    // Set envVars in constructor
    this.envVars = {
      NAME: env.name,
    };
  }
  sleepAfter = "30m";
  async onStart() {
    console.log("Container started");
  }
  enableInternet = true;
  onStop() {
    console.log("Container shut down");
  }
  onError(error) {
    console.log("Error:", error);
  }

}
export default {
  async fetch(request, env, ctx) {
    // Trigger Durable Object
    console.log("Manual trigger → starting container");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          // You can pass dynamic values here
          MANUAL_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
    return new Response("Container manually triggered and executed", {
      status: 200,
    });
  },
  async scheduled(controller, env, ctx) {
    console.log("Cron triggered");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          CRON_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
  },
};

import { Container, getContainer } from "@cloudflare/containers";

export class dummy extends Container {
  constructor(state, env) {
    super(state, env);
    // Set envVars in constructor
    this.envVars = {
      NAME: env.name,
    };
  }
  sleepAfter = "30m";
  async onStart() {
    console.log("Container started");
  }
  enableInternet = true;
  onStop() {
    console.log("Container shut down");
  }
  onError(error) {
    console.log("Error:", error);
  }

}
export default {
  async fetch(request, env, ctx) {
    // Trigger Durable Object
    console.log("Manual trigger → starting container");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          // You can pass dynamic values here
          MANUAL_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
    return new Response("Container manually triggered and executed", {
      status: 200,
    });
  },
  async scheduled(controller, env, ctx) {
    console.log("Cron triggered");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          CRON_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
  },
};

import { Container, getContainer } from "@cloudflare/containers";

export class dummy extends Container {
  constructor(state, env) {
    super(state, env);
    // Set envVars in constructor
    this.envVars = {
      NAME: env.name,
    };
  }
  sleepAfter = "30m";
  async onStart() {
    console.log("Container started");
  }
  enableInternet = true;
  onStop() {
    console.log("Container shut down");
  }
  onError(error) {
    console.log("Error:", error);
  }

}
export default {
  async fetch(request, env, ctx) {
    // Trigger Durable Object
    console.log("Manual trigger → starting container");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          // You can pass dynamic values here
          MANUAL_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
    return new Response("Container manually triggered and executed", {
      status: 200,
    });
  },
  async scheduled(controller, env, ctx) {
    console.log("Cron triggered");
    const container = getContainer(env.DUMMY);
    await container.start({
      startOptions: {
        envVars: {
          CRON_TRIGGERED_AT: new Date().toISOString(),
        },
      },
    });
  },
};

For reference this is my worker code, and my container is a python function.

MMaulik Tyagi No, it is just a function which is supposed to run on its own when container sta...

kian•10/14/25, 3:00 PM

I don't think the Containers library will let you start a Container without it having a web server / port for us to check on.

kian•10/14/25, 3:01 PM

The direct API available with Durable Objects (which we're wrapping in the library) might be a better fit: https://developers.cloudflare.com/durable-objects/api/container/

christianklotz•10/14/25, 3:04 PM

I've been using the Sandbox SDK, and while it works locally, once deployed to Cloudflare, as the DO is trying to write a file with "[HTTP Client] Making POST request to http://localhost:3000/api/write""[HTTP Client] Making POST request to http://localhost:3000/api/write", I get the following error message:

"Sandbox error:",
"Error: Container connectivity was lost"

"Sandbox error:",
"Error: Container connectivity was lost"

DO ID: dcb4030e8dbbd797c6f34192fba09c75e77c42d32244b52680d3431302e0a7eedcb4030e8dbbd797c6f34192fba09c75e77c42d32244b52680d3431302e0a7ee

After some debugging it looks like, the sandbox preflight succeeds, the first call to writeFilewriteFile causes the container to lose connectivity, and then it kinda 'hangs'.

Anyone seen similar things before?

kian•10/14/25, 3:42 PM

What's the application ID for the Containers app? It's the UUID in the URL when you go to the Containers overview (Workers & Pages in sidebar -> Containers -> click on the app)

Kkian What's the application ID for the Containers app? It's the UUID in the URL when ...

christianklotz•10/14/25, 3:48 PM

a03e7cbd-ed24-485c-92c4-eeb9bac1ae5da03e7cbd-ed24-485c-92c4-eeb9bac1ae5d

kian•10/14/25, 3:51 PM

I think that’s your account ID - the Containers application is a UUID that comes later

kian•10/14/25, 3:52 PM

/accountId/containers/applicationId/ - something like that

Kkian I think that’s your account ID - the Containers application is a UUID that comes...

christianklotz•10/14/25, 3:53 PM

corrected above

kian•10/14/25, 7:00 PM

I'm not seeing much in the way of errors on our side - I can see the "Container" (in this case the Sandbox SDK entrypoint) exited successfully (exit code 0) at 15:15 UTC.

kian•10/14/25, 7:00 PM

Is it always reproducible for you when using that writeFilewriteFile API?

Kkian I'm not seeing much in the way of errors on our side - I can see the "Container"...

christianklotz•10/14/25, 8:28 PM

Thank you for looking into it! Yeah, it's always writeFilewriteFile. Interestingly I get this on executeexecute:

"[HTTP Client] Error executing in session:",
"Error: Session 'sandbox-default' not found"

"[HTTP Client] Error executing in session:",
"Error: Session 'sandbox-default' not found"

Not sure if related.

I am whipping up a more isolated implementation right now to see it still breaks

Cchristianklotz Thank you for looking into it! Yeah, it's always `writeFile`. Interestingly I ge...

christianklotz•10/14/25, 9:58 PM

After a bit more digging it feels like it's more an issue with the Sandbox SDK itself than containers. The basic setup works for me locally but makes the worker fail with "Failed to create session""Failed to create session" once deployed.

Alex Dahl•10/15/25, 9:14 AM

Has anyone checked the network speed for R2 <=> containers? My workload is for semi-big files 1GB~ on R2, would be awesome if the containers had access to cloudflares internal network

CodingCoop | Co-Founder Nullshot•10/15/25, 9:21 AM

@kian | Containers any plans to set instance type dynamically or do i need a unique DO / Container class per instance type? I want users to choose their instance size.

Cchristianklotz After a bit more digging it feels like it's more an issue with the Sandbox SDK i...

christianklotz•10/15/25, 9:34 AM

Update on the basic setup: this works now which may have purely a matter of me having made requests before the instances to be provisioned. Still looking into why the Sandbox SDK fails

CodingCoop | Co-Founder Nullshot•10/15/25, 9:38 AM

You may need to create the sesion first @christianklotz - then run the command baesd on the session object returend by the createSession object. I haven't used the default session commands personally though ( the direct ones in the sandbox ) but ive been working out of the sandbox createSession with unique ids passed in which has worked well for past month or so.

christianklotz•10/15/25, 9:39 AM

Yeah, that's what I'm doing. And it works locally, for some reason it doesn't once deployed

CodingCoop | Co-Founder Nullshot•10/15/25, 9:48 AM

thats odd if its working locally, but not remotely.

I've heavily modified the sandbox sdk, but one thing I recall was that when i create session in multiple places, it would create a new session although it was the same id, so I created it so it woudl return the same session at the container level under isolation.ts

/**
 * Manages isolated sessions for command execution.
 * Each session maintains its own state (pwd, env vars, processes).
 */
export class SessionManager {
  private sessions = new Map<string, Session>();
  
  async createSession(options: SessionOptions): Promise<Session> {
    // Validate cwd if provided - must be absolute path
    if (options.cwd) {
      if (!options.cwd.startsWith('/')) {
        throw new Error(`cwd must be an absolute path starting with '/', got: ${options.cwd}`);
      }
    }
    
    // Return existing session if it already exists
    const existing = this.sessions.get(options.id);
    if (existing) {
      console.log(`[SessionManager] Returning existing session '${options.id}'`);
      return existing;
    }
    
    // Create new session only if it doesn't exist
    const session = new Session(options);
    await session.initialize();
    
    this.sessions.set(options.id, session);
    console.log(`[SessionManager] Created new session '${options.id}'`);
    return session;
  }

/**
 * Manages isolated sessions for command execution.
 * Each session maintains its own state (pwd, env vars, processes).
 */
export class SessionManager {
  private sessions = new Map<string, Session>();
  
  async createSession(options: SessionOptions): Promise<Session> {
    // Validate cwd if provided - must be absolute path
    if (options.cwd) {
      if (!options.cwd.startsWith('/')) {
        throw new Error(`cwd must be an absolute path starting with '/', got: ${options.cwd}`);
      }
    }
    
    // Return existing session if it already exists
    const existing = this.sessions.get(options.id);
    if (existing) {
      console.log(`[SessionManager] Returning existing session '${options.id}'`);
      return existing;
    }
    
    // Create new session only if it doesn't exist
    const session = new Session(options);
    await session.initialize();
    
    this.sessions.set(options.id, session);
    console.log(`[SessionManager] Created new session '${options.id}'`);
    return session;
  }

CodingCoop | Co-Founder Nullshot•10/15/25, 9:48 AM

But that wouldn't effect your local vs cloud...

christianklotz•10/15/25, 10:12 AM

A noticeable difference compared to the basic setup described in the Sandbox SDK docs is that the container state shown in the dashboard remains Active (instead of going back to Ready). Not sure if this is related tho

Allen•10/15/25, 12:06 PM

Hi, is there any way to avoid cold start? Because I have very high requirements for real-time performance.

pandalambda2•10/15/25, 12:12 PM

ping it to death - looks at cron triggers, but nothing will guarantee it 100%, can be evicted for different reasons all the way down to a node failure

Allen•10/15/25, 1:18 PM

Thanks for your suggestion. I have considered this method before, but it may not work because of the global node. The location I ping will be different every time, so this cannot solve the problem.

Ppandalambda2 ping it to death - looks at cron triggers, but nothing will guarantee it 100%, c...

Allen•10/15/25, 1:18 PM

@pandalambda2

pandalambda2•10/15/25, 1:20 PM

if you use the same sessionid it will

pandalambda2•10/15/25, 1:20 PM

since the worker which could be anywhere on the network, will route to the specific DO

pandalambda2•10/15/25, 1:20 PM

and DO is 1:1 with the container

Thomas•10/15/25, 4:05 PM

fyi the automatically-set runtime environment variables mentioned here (specifically the durable object id) is just set to 64 'x's in dev https://developers.cloudflare.com/containers/platform-details/environment-variables/

is that intentional? if so it'd be lovely if mentioned in the docs

Cloudflare Docs

Environment Variables

The container runtime automatically sets the following variables:

JJon M.Any plans to actually show rollout progress when you update a container?

kian•10/15/25, 5:12 PM

There is already a rollout bar in the dashboard, are you referring to something else?

TThomas fyi the automatically-set runtime environment variables mentioned here (specific...

kian•10/15/25, 5:13 PM

That's intentional, we'll add it in as a note to the docs. It usually represents the DO backing your Container but in local development it's just powered by Docker so there isn't one.

kian•10/15/25, 5:14 PM

Are your Containers gracefully shutting down? If you had a max_instancesmax_instances of 10 and rollout steps of 20, 10020, 100 then we can't progress past 20% (aka 2 instances) until those 2 instances have stopped & we've brought them back up with the new settings.

kian•10/15/25, 5:14 PM

If they don't handle SIGTERM themselves then we give them 15 minutes before they're killed.

kian•10/15/25, 6:30 PM

Are you responding to a request and then starting compute like "hey, start this task -> yep, started"?

kian•10/15/25, 6:30 PM

The current lifecycle model of sleepAftersleepAfter kinda has a web server focus where once you respond, sleepAftersleepAfter starts and then we'll send a SIGTERMSIGTERM to your Container.

kian•10/15/25, 6:30 PM

There is an onActivityExpiredonActivityExpired lifecycle hook in the Containers class where you can do your own logic to decide if sleepAftersleepAfter should start counting down

kian•10/15/25, 6:46 PM

https://github.com/cloudflare/containers/

kian•10/15/25, 6:46 PM

Lots of the docs are in the README of the library right now but we are working on moving this library into the runtime so it just works as a normal binding

kian•10/15/25, 6:46 PM

onActivityExpiredonActivityExpired is basically your way to intercept the sleepAftersleepAfter invocation for now

kian•10/15/25, 6:47 PM

There's also some other APIs on the way like setting a hard timeout (my Container should stop running after 20 minutes from being started)

dev•10/15/25, 6:58 PM

what's the difference between a sandbox and a container?

kian•10/15/25, 7:12 PM

Containers is the primitive where the code is running - the Sandbox SDK runs your commands inside Containers

No, it is just a function which is supposed to run on its own when container starts, it is a cron co

Similar Threads

Similar Threads

Similar Threads