It killed the category in my mind, it isn't even your fault. I now feel far more comfortable running on bread-and-butter tools, like AWS/GCP/Azure with Kubernetes. The overhead sucks, but at least I can plan for things better than I can when hosting with fast-moving PaaS providers.
Hosting is too important of a problem to wholly outsource entirely to a PaaS platform if it's subject to shuffling at a rate I can't control (exception: personal projects with no real availability expectations). That's the double edged sword with platforms like these. They let you get your application online rapidly, but you could be subject to unforeseen technical debt at the hosting provider's will. I learned (the hard way) that I'm not a fan on managing risk under those terms.
Still your point is very valid and I guess only time can tell!
For websocket, you can move it to another "not-serverless" hosting as well.
Splitting then combine is far more easier than combine then splitting.
At that point, I'd rather just go fully in on Kubernetes and keep the benefits of containers, rather than using two cloud providers.
Me, setting that up from scratch on a single VPS, that might get hacked if I mess it up, and then my customer's availably is compromised? I wouldn't want to be in that situation.
Currently we're starting out by looking at feasibility with Apollo. If we can manage to get that to work, then hopefully we can move on to other frameworks.
Pusher does Websockets. It can only be so opinionated, since it's a fairly focused, well-defined problem: Websockets. I'ts less likely to be subject to breaking changes versus Now. I'd say they have both roughly the same chance of randomly shutting down, with only a few months notice.
I'm definitely not your target audience, so take what I'm about to write with a grain of salt.
I didn't register, and only checked out your Landing Page and your linked Documentation...
The first issue i had was how you didn't mention healthchecks or log aggregation anywhere... how would a developer troubleshoot issues if they'd chose to go with your service? and do they need to use external monitoring to be notified about issues?
my next issue was with the database... how would developers do their database migrations? do they need to connect to their database directly and execute them from their workstation? If so, does that mean that the database is open to dog and world?
How would a developer set secrets and other runtime variables that cant be part of the repository? I couldn't find anything about that in the docs either.
Honestly, nothing about the product made me think PaaS. Its more like an offer to host a single threaded web application of some select languages... But i wish you luck!
The competition is fierce though, especially with Amazon pushing for serverless, Heroku and self hosted alternatives like Dokku around.
One question: for the two lower cost plans with weekly backup: if there is a hardware failure and you need to restart all apps on a new server, how much time would this take? I am not asking for an estimate if the data center you use goes down, just asking about an estimate for spinning up apps on a new server.
I ask because I like to host small experiments. If apps are down occasionally for a half hour or an hour that is OK, but a few hours isn’t.
The time to spin a new server and set up the apps back on it is no more than a few minutes (depending if you had a DB and how large it is). You can see it in action when you scale an app up, it will spin a new server, import back the DB on it, build your app and switch DNS to the new location. Rarely takes more than 5 minutes.
I think tho if something happens at the hardware level and we lose our servers we would seriously consider switching providers.
- Can you scale up to more app server instances?
- Where are your servers running? Based on location and the pricing progression, I'm guessing Scaleway?
- How are logs handled?
There's a typo in your docs, first line below "Source Code", it says "maneer" instead of "manner".
I'm curious how your projects are doing finally. Would you mind sharing? Maybe even via an open dashboard like Buffer and Ghost are doing?
I hope you're either doing good already or will do soon!
If you're interested: for now I've only monetized two projects beside Backery (Nucleus and Harmony). Nucleus is doing right now around $200 / month (growing) and Harmony around $150 monthly, slowing decreasing with time. I like building too much but should focus more on selling, even tho it feels a bit counterintuitive to me. An open dashboard is a good idea, I love these. Can definitely put one in place once I have some more steady revenues :)
Is there a way to store immutable files (something similar to S3)?
Is the filesystem available and persistent?
Regarding PostgreSQL and other databases, do you backup the WAL? (DigitalOcean Managed Databases backups the WAL every 5 minutes.)
- No, for now it's only application hosting. You should use an external service like S3 to store immutable files.
- Although filesystem is available it might reset on server upgrade / scaling / migration. That happens very rarely (safe for temp files) but general files should be stored somewhere like S3.
- For PostgreSQL backups, they are actually done with dumps (pg_dump) so it's not a base backup.
Would be nice if you support Elixir (you don't have to, maybe it's not worth it since demand would not be high)
Congrats on launching.
Sounds like a pain.
A serverless DB is like Firebase or Fauna, where you pay by number of queries, storage, etc, and it scales up and down automatically much like cloud functions.
Unfortunately after the parse.com fiasco I have vowed to never again use a PaaS/BaaS service again for important deployments.
I wish the OP success in their efforts though. I think it looks like a great service, and believe there are potential customers out there who can accept the risk and deploy on this platform.
 : https://github.com/parse-community/parse-server
In the end we decided to rewrite the whole thing as a Java/Spring/Postgres monolith on Kubernetes. The rewrite took 3 months from decision to production and has been running fine for two years now. Initially on AWS and more recently the staging/dev environments have been moved to DigitalOcean in a couple of hours.
After the pending acquisition we’ll probably move the whole thing to Azure and I expect that to take a couple of days.
if you are happy on DO, why switch to Azure ?
The switch to Azure will likely happen post-acquisition to move everything into the infrastructure of the buyer.
It is single host. It requires still managing the host node you run it on. Dokku is nice and they did a good job mimicking the Heroku tool chain, but it is not even close to actually providing the value Heroku gives.
(I used Dokku like 5-6 years ago)