Know what you’re running
Setup checks projects and limits apps, but running unfamiliar code still carries risks.
When code runs
Reading a project runs none of its code; building and starting it do.
| Stage | Where | Runs project code |
|---|---|---|
| Read the project | Setup control plane | Runs project code: No |
| Write the recipe | Setup and model provider | Runs project code: No |
| Build the app | BuildKit on the runner | Runs project code: Yes |
| Run the app | Containers on the runner | Runs project code: Yes |
How apps are restricted
Recipes exclude host access options; running apps use restricted containers and private networks.
Recipe restrictions
- No host folders or Docker socket
- No privileged mode or added capabilities
- No devices except GPU option
- No host network, PID or IPC
- No sysctls or security overrides
While apps run
- CPU, memory, processes, logs: limited
- Docker seccomp and AppArmor defaults
- gVisor or Kata when installed
- Declared internet access through filtered proxy
- Private networks and cloud metadata blocked
- Declared HTTP port by default
- Other ports require operator permission
- Separate named volumes per app
- Trials: 60 minutes by default
Your accounts and permissions
Setup encrypts stored credentials; apps receive only their own scoped credentials.
- Assistant changes need signed confirmation
- Restore and removal need extra acknowledgment
- Assistant follows your permissions
- No assistant access to administration
- No credentials in chat
- Workspace rules apply through API
- Only confirmed resource plans applied
- Audit entries cannot be edited
- Public status pages off by default
Risks that remain
Builds can reach your LAN; use a separate virtual machine or block private ranges for build containers.
- Standard containers share the host kernel
- Apps can exhaust their resource quota
- Cloud builds in microVMs: planned
Report a security issue
Send reproduction steps privately by email. security@setup.run