Startup Scripts
Write your setup once, save it, and attach it to any deployment. It runs as root on every fresh boot, so a new box arrives configured instead of empty.
Save once, attach anywhere
A startup script is a named, reusable init script that lives in your workspace, not in a particular deployment. Write it in the console, then pick it from a dropdown in the deploy form for any instance you launch afterwards — one script across as many boxes as you like.
Bash, Python, or anything else with a shebang. Scripts run as root, so you can install packages and touch system paths directly, or drop privileges yourself if you would rather not.
What it is actually for
Clone your repo, pull weights from your bucket, install the two CUDA packages your model needs, mount a share, start a metrics exporter, add your dotfiles. The things you would otherwise paste into a fresh SSH session every single time.
It matters more than usual on a multi-provider marketplace. If your environment is a script rather than a memory, taking a cheaper GPU on another provider stops being a rebuild — and combined with a workspace snapshot you have both halves of a portable setup: the environment and the state.
Editing a script does not touch running boxes
Scripts run at boot, so editing one affects future deployments only — a running VM does not re-execute it. The management page shows every script you have saved and how many instances use each, so you can see what an edit will and will not reach.
FAQ
When does a startup script run?
On first boot of a fresh deployment, as root, before you connect. It runs once per new instance rather than on every restart of your own processes.
Can I reuse one script across many GPU deployments?
Yes — that is the point. A script is saved in your workspace and selected from a dropdown at deploy time, so a single script can be attached to any number of instances.
What languages can a startup script be written in?
Anything with a shebang — bash and Python are the common cases. Scripts execute as root, so you can install packages and modify system paths directly, or drop privileges yourself.
If I edit a script, do my running instances change?
No. Editing a script only affects deployments created afterwards; running VMs do not re-execute it. The console shows how many instances currently use each script.
