Good news, everyone! Playground persistence - by far the most frequently requested feature - is finally in production! It is now possible to preserve the state of the playground VMs' filesystem on exit and restore it on the next day, week, or even quarter 🎉

From the UX standpoint, the changes are minimal:

• The running playground page now includes a new Stop button (in the top right corner), which differs from the historically available Terminate button: stopping shuts down the playground but preserves the rootfs state for later use, while terminating shuts down the playground and immediately disposes of all its drives.
• Next to the Stop button, a tiny Cloud pictogram is added - clicking it makes the playground stop on expiration (instead of the default destroy action) and auto-stores the playground state.
• The playground's front page now shows a list of stopped playground runs, with Resume and Delete buttons.
• Stored state is kept in a remote storage for 6 months after the last use, and up to 100 GB of data is currently allowed.

​

Persistent playgrounds are only available on the premium tier (because storage is relatively expensive), but the release also includes a number of features and improvements available for everyone:

• Playground machines can now be rebooted (sudo reboot).
• Playground machines can now be stopped (sudo shutdown or sudo poweroff) and restarted (via a UI button) independently of the playground itself.
• SSH over VSOCK is now used by default, making the initial booting much more snappy (there is not enough stats on the graph yet, but it feels like I shaved off 3-5 seconds on average from every playground boot time - yes, it means that some of them fire up almost instantly).
• The bare-metal fleet capacity has been more than doubled, meaning more compute and space resources for everyone.

With all these news capabilities, from a learning & experimentation standpoint, iximiuz Labs' playgrounds have become almost as powerful as typical cloud VMs (e.g., AWS's EC2 instances or DigitalOcean's droplets). But they might as well boot faster than said cloud offerings and most certainly are 10x cheaper to use 😉

What's next:

• Allow saving a stopped playground run as a custom playground (such a custom playground would be a read-only template that can be used to spin off any number of new read-write runs of it).
• Allow using persistent playgrounds in content (to save progress while taking a tutorial or solving a challenge).
• Write docs, tutorials, and technical deep dives on all things persistence - it's a very fruitful area, and I've gotten a ton of experience to share.

As many of you know, I started working on this feature back in April, and I couldn't have been more wrong with my initial estimate that it would take me just 2 weeks to develop​. The first batch of work lasted Apr 29th - Jun 18th and mainly consisted of the storage driver rewrite (a naive device mapper implementation was replaced with fancy copy-on-write ZFS snapshots that can be sent and restored over the network) and adding support for multi-network playgrounds and multi-drive VMs.

If I recall correctly, that PR ended up being about 16,000 lines of mainly backend code, which felt huge at the time. So when I reapproached the problem in October, I was quite sure (again 🤦‍♂️) that this time it wouldn't take longer than 2 more weeks and would require mainly user-facing adjustments. And 6 weeks and 25,000 lines of hardcore backend code later, the feature is finally in production 🚀

I'm very grateful for all the support I received from the community during these tough weeks months of work, and to recognize that and also to make the persistent playgrounds significantly more accessible, I'm officially announcing the start of the Black Friday Sale. The discount this year is massive - it's not a steal but a plain robbery - hope you'll like it as much as the feature itself.

Happy hacking!

Cheers

Ivan