As the sandbox feature has developed and especially now that Docker is included, the primary use case in mind is to use Railway sandboxes to add horsepower to GitLab runners. That is, keep a single small/cheap GitLab runner running 24/7 and this GitLab runner delegates work to Railway sandboxes which allows me to effectively auto-scale my runner down to near-zero and up to a much higher limit than I can afford with a single server. Has anyone explored doing this yet?

Example:

1. Runner starts, logs into Railway CLI
2. Checks for a named sandbox checkpoint specific to the project
3. If the checkpoint doesn't exist, it creates a sandbox and seeds it via git or perhaps rsync and creates a checkpoint
4. If the checkpoint does exist, create a new sandbox instance and update it with the correct state (e.g. via rsync - both the repo and also caches like npm or docker images)
5. Run the CI/CD job on the sandbox then tear it down

I think the key is using checkpoints to effectively keep the cache alive. Running each pipeline with a cold cache (clone repo, install packages, build/pull docker images), would otherwise negate or severely diminish the benefit of the additional processing power availability.

Anyone know if the Docker daemon image cache is included in the checkpoint?

Good idea or bad? Feedback welcome.