# Are Cloud Sandboxes a Good Fit for a Hackathon Team?

> 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.

Source: https://sandboxer.com/guides/sandboxes-for-hackathons. Updated 2026-10-27.

**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](/guides/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](/guides/ssh-into-a-cloud-sandbox-from-vs-code-or-cursor), [code-server](/guides/run-code-server-vs-code-in-the-browser) |
| 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](/guides/run-claude-code-in-a-cloud-vm), [Run coding agents in parallel](/guides/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](/guides/give-a-sandbox-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](/guides/run-a-service-that-comes-back-after-resume), [Idle auto-pause and wake on use](/guides/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](/guides/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](/docs/organizations) |
| - | - | - |
| 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.

```bash
#!/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

```bash
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
```

```text
{"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

```bash
sbx snapshot share team-starter
```

```json
{"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

```bash
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"
```

```text
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](/docs/snapshots#share-a-template-with-another-account).

### 4. Private while building, public for judging

```bash
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
```

```text
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

```bash
sbx stop $id --wait
curl -s https://hearty-prime-kestrel-8000.box.sandboxer.com/api/health
sbx resume $id
```

```text
<!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

```bash
sbx extend $id --hours 6
sbx usage $id
```

```json
{"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](/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](/guides/idle-auto-pause-and-wake-on-use) 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](/guides/handle-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.

### Will the judges' link still work on Monday?

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](/docs/snapshots#share-a-template-with-another-account): 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](/guides/clean-up-orphaned-sandboxes).

## Related

- [Turn a sandbox into a reusable template](/guides/turn-a-sandbox-into-a-reusable-template)
- [Give a port in a cloud sandbox an HTTPS URL](/guides/give-a-sandbox-port-an-https-url)
- [Run a service that comes back after resume](/guides/run-a-service-that-comes-back-after-resume)
- [Hosting](/docs/hosting)