I feel like one of the problems (this might solve) is that the servers can start up instantly since they are firecrackers so I can assume that a service shuts down automatically after some time and then they auto start when a server points to a particular resource aka sleeping (similar to how railway's sleeping mode works)

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