Still, there is the advantage of simplicity not having to deal with the web console etc. Some people may enjoy this
A suspended machine only costs its disk usage to the hoster. You can have 800 of them on a machine with 4TB SSD. You can't say the same for VPS at all.
The service seems neat, but the pricing seems more to be a novelty than a real service. Maybe I’m missing something.
Can be pretty fast.
The UX here seems really nice, but after spending a couple minutes setting up the VPS, I essentially get the same UX (aka just ssh in and so stuff).
I’d potentially be willing to pay some premium over a standard VPS, but certainly not a 10x premium…honestly probably not even 2x.
And the big benefit of a remote box is that you can offload long running tasks to it.
https://learn.microsoft.com/en-us/azure/azure-functions/dura...
"30 hours of wake time per month (~5 concurrent users avg), averaging 10% of 2 CPUs and 1 GB RAM"
Does that mean it would sit available but using 0% when there's nobody on the site, and just bill for usage when web traffic is causing the server to do work? So if the web app went a month with no visitors it would cost nothing (except for the file storage fees)?
Yes that's the idea. The public URL for a sprite is served by a (free) load balancer. The sprite is normally suspended, gets resumed when a request comes in, then suspended again. Not sure on the exact timeouts, they probably don't suspend immediately after a response is sent.
Sprites pricing is based on usage, not reserved capacity, so depending on what you're doing I think it can actually be cheaper than Shellbox. You'll have to stay below 1GB of memory and have the CPU be mostly idle, which I'm not sure common workloads will.
With this service, it seems like the VM underpinning your session is suspended (like as if you were to suspend-to-RAM or hibernate your laptop), and then resumed the next time you sign in, so not only is the filesystem in the same state as it was during your last session, but any background processes that have spun up since then are resumed as well, and are still running.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernat...
Can then spawn a new instance from the snapshot and it should unhibernate
Whether the OS will like that... That's another point. As there will be things that change like smbios etc
A VPS gives you persistent state, but it still assumes you’re willing to manage that state. The distinction here seems less about what’s possible and more about who carries the ongoing operational burden: the user or the service.
That being said One of the ideas I like about this is the idea that you can seperate 1 server into multiple chunks for fast loadouts using firecracker
I have built something for my own internal use case on top of firecracker + automatic ssh and I will probably share it in the future but the key idea I like about shellbox is that I can see this one service on which I can build a product, have a genuine use case and they mentioned open sourcing (I hope they do, mine implementation of firecracker-ssh uses bottlefire + golang/ssh library) and you can always cut out the middle man (they are more transparent about it imo than I've seen people)
Honestly, they can add multiple more higher level servers as well and have them be slowdown at 0.005$ as well, I feel like this will be the key unlock of shellbox.dev and I am hopeful that they might work on it.
There are tools for almost everybody now in this space which didn't exist a month ago. Exe.dev for people (currently its burning VC money but once it gets stable) would be for people who have like 25-40 vms and have a constant amount of VM's and shellbox is gonna feel more like for those where you can one day probably have a simple abstraction and you can host software rather easily and use it and then dump the server to either completely remove it or just be when you might need it
Another issue is that if shellbox.dev is like the story of icarus, if they fly too high, I think they might win the war but they will lose the battle and if they fly too low or the competitors and it's major differences just become price, they both might compete to the bottom and the problem is that in times of emergency combined with the presence of Murphy's law, when disaster hits (they are basically arbitraging unused hardware space in the idea that long term enough users might come that things would be much rather full, they need a buffer because the servers might have unused compute for which they will have to pay
So if someone flies completely tries to lowball the price, what would end up happening is that in case of diasaster, they might actually fold/lose money and sustainability practises would be thrown out of the way (Just ask anyone in lowendtalk what happened to veloxmedia recently)
Honestly I am pretty frugal so I would still argue with your point though. I feel like they can still slash the prices in half of suspended costs because I think sprites.dev (their competitor) costs nothing/negligibly virtually when they are not running.
Shellbox does have this one benefit in comparison to sprites.dev in that they are more "No signup, no config, no complexity" and their small niche scale feature might still make sense.
Sprites.dev uses fly.io (a deeply awesome company) as well and it seems to have the most momentum right now as well
I think that these companies/projects will change their pricing and multitude of things will happen. I am really excited about this space.
Someone should probably create a comparison between exe.dev, sprites.dev and now shellbox.dev comparing each and every
CX23 is €3.49/mo, but you can save 0.50€ if you forgot ipv4.