Skip to content
sandboxer
Start free trial
Guides · Who it's for

Are Cloud Sandboxes a Good Fit for a Hackathon Team?

Updated October 27, 2026 .md

Short answer: Set up the stack once, save it as a named snapshot and give teammates a share code, so each gets the same machine in about 3 seconds. Run the demo as a systemd unit, host it with sbx host --public, and set a TTL that outlasts judging. A small sandbox for 48 hours costs $0.86.

This page is for a team building something over a weekend, and for organizers who hand out machines. The hard parts at a hackathon are rarely the code. They are four laptops with four different setups, a demo that only runs on one of them, and a link that is dead when the judges click it. Each job below has the answer, the feature that does it and the guide with a full run. The end-to-end example ran on prod on 2026-10-27.

The jobs, and what to use for each#

Job Short answer Sandboxer feature Worked guide
Same stack for every teammate One person sets it up and saves it; the others start from a share code sbx snapshot <id> <name>, sbx snapshot share <name>, sbx new --from bsh_… Turn a sandbox into a reusable template
Working in it from your editor SSH from VS Code or Cursor, or code-server in the browser sbx ssh-config, sbx host <id> 8080 SSH from VS Code or Cursor, code-server
A coding agent that can't wreck your laptop Run the agent in the sandbox with permissions skipped; run several on separate VMs sbx new, one VM per agent Run Claude Code in a cloud VM, Run coding agents in parallel
A link the judges can open Private while you build, public for judging sbx host <id> <port> --public Give a port an HTTPS URL
A demo that is still up at judging Long TTL, the app as a systemd unit, and know which stops wake on a click --ttl, sbx extend --hours, idle auto-pause A service that comes back after resume, Idle auto-pause and wake on use
Machines for every participant (organizers) One small --no-env sandbox each, from one snapshot, paced under your start limit sbx new --from <name> --no-env, sbx limits --json Sandboxes for classrooms and teaching

Teammates on separate accounts, or one organization?#

Most hackathon teams are friends on separate accounts. That changes what you can share.

Separate accounts One organization
Starting from your setup Give them a share code; they run sbx new --from bsh_… Still a share code: named snapshots are visible only to their creator
Who pays Each teammate pays for the sandboxes they start One wallet, priced per seat
One shared box everyone works in Not possible: a sandbox belongs to one account sbx share <id>, then every member can open and exec into it
What a teammate gets A copy of the disk with your logins, API keys, secret files, repository credentials and SSH keys removed The same sandbox

For a weekend, separate accounts and a share code is the simpler setup. Each person has their own VM, so a broken npm install on one doesn't block the others. Push to a shared Git repo as you normally would, and pick one sandbox to serve the demo.

A starter for the team, end to end#

We ran this on 2026-10-27 at 12:01 UTC with small sandboxes, from a machine outside Sandboxer's network. The starter is a Python standard-library app with an /api/health route, installed as a systemd unit so it starts on every boot. Your stack goes in its place.

#!/bin/bash
# setup.sh: run once in the builder sandbox
set -e
mkdir -p ~/demo && cp ~/starter/app.py ~/demo/
sudo tee /etc/systemd/system/demo.service >/dev/null <<'UNIT'
[Unit]
Description=Hackathon demo app
After=network.target
[Service]
User=user
WorkingDirectory=/home/user/demo
ExecStart=/usr/bin/python3 /home/user/demo/app.py
Restart=always
[Install]
WantedBy=multi-user.target
UNIT
sudo systemctl daemon-reload
sudo systemctl enable --now demo
sleep 1
curl -s localhost:8000/api/health

The app binds 127.0.0.1:8000. A sandbox has a public IPv6 address, so keep servers on localhost and let sbx host --localhost relay to them.

1. Build it once, save it, delete the builder#

id=$(sbx --json new --name team-builder --type small | jq -r 'select(.event=="ready") | .id')
sbx exec $id "echo $(base64 -w0 starter.tgz) | base64 -d | tar xz && bash starter/setup.sh"
sbx snapshot $id team-starter
sbx delete $id --yes
{"ok": true, "host": "quick-royal-chalk", "uptimeSeconds": 0.9}
Created symlink /etc/systemd/system/multi-user.target.wants/demo.service → /etc/systemd/system/demo.service.

The named snapshot outlives its source, so the builder can go.

2. Make a share code#

sbx snapshot share team-starter
{"ok": true, "type": "snapshot.share.created", "name": "team-starter", "share": {"codePrefix": "bsh_…", "id": "shr_O3HvEzZ9D8M5i4ps", "status": "active", "useCount": 0, …}, "shareCode": "bsh_…"}

The code is printed once. Send it to your team the way you'd send a password: anyone with it can start a copy of that disk on their own account.

3. A teammate starts from it#

id=$(sbx --json new --from bsh_… --type small --ttl 172800 | jq -r 'select(.event=="ready") | .id')
sbx exec $id "systemctl is-active demo; curl -s localhost:8000/api/health"
active
{"ok": true, "host": "hearty-prime-kestrel", "uptimeSeconds": 7.9}

The demo service was already running on the new machine. Nothing was reinstalled. We started this copy from the share code on the same account; we did not test a second account, so the login-stripping described above is from the snapshot docs.

4. Private while building, public for judging#

sbx host $id 8000 --localhost --title "Team demo"
curl -s -o /dev/null -w "%{http_code}\n" https://hearty-prime-kestrel-8000.box.sandboxer.com/api/health
curl -s -o /dev/null -w "%{http_code}\n" "https://hearty-prime-kestrel-8000.box.sandboxer.com/api/health?_token=…"
sbx host $id 8000 --localhost --public
401
302
{"access":"public","isProtected":false,"localhost":true,"url":"https://hearty-prime-kestrel-8000.box.sandboxer.com"}

Without the token the request got 401; with it, a 302 set a cookie. After --public, five requests from our machine each returned 200 in 0.19 seconds. The address stays the same across stop and resume, so you can put it on the submission form early. Going back to --private mints a new token, and the old private link stops working.

5. Stop it, see what judges would see, bring it back#

sbx stop $id --wait
curl -s https://hearty-prime-kestrel-8000.box.sandboxer.com/api/health
sbx resume $id
<!doctype html>… Not found … No sandbox uses this address. … HTTP 404
{"event":"ready", "memoryRestored":true, "resumeReason":null, "ttl":172800, …}
{"ok": true, "host": "hearty-prime-kestrel", "uptimeSeconds": 28.7}

This is the failure to plan for. On 2026-10-27, while a sandbox was stopped by you or by its TTL, its URL returned this 404 page, and a judge's click doesn't wake it. Only an idle pause wakes on a request. Here the resume restored memory, so the same process kept answering. If a resume lands on a machine with a different CPU type, it boots from disk instead, and the systemd unit starts the app again.

6. Give it a deadline after judging, and check what it cost#

sbx extend $id --hours 6
sbx usage $id
{"ttl":21600,"archiveAfter":"2026-10-27T18:03:20.982079Z"}
{"ok":true,"type":"sandbox.usage","billingMultiplier":0.5,"dollars":0.00023,"running":true,"seconds":23,"secondsPerDollar":100000,…}

seconds is counted in default time: the sandbox had run about 46 seconds at small's half rate. Afterward we deleted the sandbox (sbx info returned 404 not_found, and the URL returned 404), revoked the share code with sbx snapshot unshare team-starter shr_…, and removed the snapshot with sbx snapshot rm. A create from the revoked code failed with 404 snapshot_not_found: "That share code is wrong or revoked."

Timings#

Single measurements from our client, so they include CLI and network time:

Step Time
Create the builder (small) 3.19 s to ready
Unpack the starter and enable the unit 1.44 s
Save the named snapshot 2.13 s
Teammate's sandbox from the share code 3.19 s to ready
Hosted URL, public, from outside 0.19 s per request (5 requests)
sbx stop --wait 2.16 s
sbx resume, memory restored 1.34 s

What a weekend costs#

Billing is per second while a sandbox runs, from pricing: small is $0.018/hour, default $0.036/hour.

Setup Arithmetic Cost
One small running all 48 hours 48 × $0.018 $0.86
Four teammates, one small each, 48 hours 4 × 48 × $0.018 $3.46
Four teammates, default, 12 working hours each, plus one small demo for 48 hours 4 × 12 × $0.036 + 48 × $0.018 $1.73 + $0.86 = $2.59

Stopped and idle-paused sandboxes cost no compute. The new-account trial is 7 days with 25 hours of machine time and needs a card on file. Machine time is counted at the default rate, so 25 hours covers 50 hours of one small sandbox.

Limits to plan around#

  • A trial sandbox can't stay up overnight on its own. During the trial, TTLs above 8 hours and --no-auto-stop are refused, you can run 2 sandboxes at once, and only small and default are allowed. A teammate on the trial must extend the demo sandbox before its 8-hour limit, or the demo should run on an account with a plan.
  • A new sandbox stops after 1 hour by default. Pass --ttl on create or run sbx extend before judging. Once stopped by its TTL, the URL showed a 404 page (on 2026-10-27) until someone resumed it.
  • Idle pause is set per plan. The default idleStopMinutes was 30 on our test account. A paused demo wakes on the next request, which the proxy holds up to 45 seconds. In the idle guide's run that first request took 0.8 seconds. To avoid even that during judging, run sbx idle <id> 0.
  • Organizers: count starts, not just seats. Creates, resumes and forks each count as a start. On the $20 plan that is 12 per minute and 60 per hour, so the first 60 participant sandboxes start in 5 minutes and the other 40 wait for the rolling hour: just over an hour for 100. On the $100 plan (30 per minute, 210 per hour) they take about 4 minutes. Create them before the opening talk. See Rate limits and concurrency caps.
  • No GPU. Sandboxes are CPU-only: small 2 vCPU/4 GB, default 4/8, large 8/16. Call a hosted model API from the sandbox if your project needs inference.
  • No smaller size after the fact. Moving a sandbox to a smaller size isn't supported yet. Start a new one from your snapshot instead.
  • No custom domain yet. The demo lives at <subdomain>-<port>.box.sandboxer.com. You can pick a readable subdomain with sbx rename <id> --subdomain <name> before you submit the link; the old URL stops resolving.

FAQ#

Can my whole team work inside one sandbox?#

Only inside an organization. A member runs sbx share <id>, and once their logins are wiped at the next start, every member can open and exec into it. On separate accounts, each teammate starts their own copy from a share code, and you share code through Git.

Only if the sandbox is running or idle-paused. After a TTL stop or a manual stop, the URL returned a 404 page in our 2026-10-27 test until someone ran sbx resume. The address itself doesn't change, so a resume brings the same link back.

Do teammates get my API keys if I share the starter?#

No, according to the snapshot docs: logins, API keys, secret files, repository credentials and SSH keys are removed from their copy, and all other files come across. Don't leave secrets in plain project files, such as a committed .env, because those are ordinary files.

What happens to everything after the event?#

It keeps running until its TTL, then stays stopped and counts toward storage. Delete each sandbox with sbx delete <id> --yes, revoke the share code and remove the snapshot with sbx snapshot rm <name>. See Clean up orphaned sandboxes.

More guides

Top AI sandbox platforms for code execution in 2026, ranked

For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.

Read the guide
Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked

For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.

Read the guide
Best Daytona sandbox alternatives in 2026, ranked

The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.

Read the guide
Best E2B alternatives in 2026, ranked

If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.

Read the guide