If you're serious about migrating off (and not just saying it in the heat of the moment), the main thing is having a plan for the database migration. That's always the painful part. Everything else is just Docker containers that run anywhere.

The correlation with scheduled restarts is interesting though. Makes me wonder if there's a cert validation issue on boot that's causing new instances to fail health checks.

What stood out from the comments: people don't want to leave the simplicity, they just can't justify the cost or trust the direction. That's exactly the gap we're trying to fill. Flat pricing (hobby plans from $5/mo, pro from $22/mo), unlimited apps per plan, and we're actually shipping features.

Not trying to be opportunistic here, but if anyone's evaluating alternatives, happy to help. We have people migrating from Heroku weekly and the feedback has been solid.

The "no new features" announcement is honest, but it forced a lot of teams into planning mode overnight. Most aren't looking for fancy features. They want reliable deployments, reasonable pricing, and to not worry about their platform disappearing. That's the gap we're trying to fill - Heroku-style DX without the Salesforce uncertainty or the sticker shock.

One thing worth considering: at $200/mo you're still managing patches, security updates, backups, and handling your own uptime. A single Hetzner VPS is also a single point of failure. The cost savings are real, but so is the operational overhead that comes back to bite you at 2am.

We built miget.com to sit in that middle ground—simpler than managing your own servers, way cheaper than Heroku. Unlimited apps on flat pricing ($5/mo hobby, $22/mo pro with dedicated CPU), so you're not penalized for scaling out. Free tier if you want to try it.

Not saying DIY is wrong—just that there are more options now between "manage everything yourself" and "$1200/mo PaaS."

That's why we built miget.com around flat pricing for unlimited apps instead of per-app billing. Makes the economics predictable, and you're not betting on a single vendor's roadmap decisions. Free tier for trying it out, hobby plans from $5/mo.

The DX concern is real though. Most alternatives either give you raw infrastructure (more ops work) or lock you into their specific tooling. Worth running some tests to see what the actual tradeoffs are for your stack.

The frustrating part wasn't just the lack of new features - it was watching the price stay high while reliability got worse. We're building miget.com partly because of that: flat pricing for unlimited apps, so you don't get nickel-and-dimed as you scale out. Starts at $5/mo for hobby projects, free tier for trying it out.

Not trying to pitch - just saying there are options now that didn't exist when Heroku was the only game in town. The PaaS space is healthier for it.

The ops planning point resonates. When you're evaluating alternatives, the question isn't just "where do I move?" but "how do I avoid this situation again?" That's why we went with unlimited apps on flat pricing instead of per-app billing. Makes the economics predictable, and you're not locked into a single vendor's roadmap decisions.

For anyone actively planning their migration: the technical migration is usually straightforward (Buildpacks, Procfiles, etc. mostly work the same). The harder part is re-architecting around the pricing model of wherever you land. Happy to answer questions if helpful.

Comments URL: https://news.ycombinator.com/item?id=46995165

Points: 3

# Comments: 1

and you should be good

1) What about memory - is it shared too? CPU is shared dynamically. Memory is still hard allocated as a guaranteed limit per workload. This was intentional because, unlike CPUs, memory oversubscription risk is significantly harder to mitigate safely at PaaS scale without introducing latency unpredictability and OOM risk. So: CPU = elastic, RAM = guaranteed / stable.

2) Is isolation compromised by this approach? No - apps don’t run on the same container host. Every app runs on its own Kubernetes node (physical or VM). The Fair Scheduler coordinates CPU fairness across nodes under a single user resource plan. This eliminates noisy neighbors and preserves app-level blast radius reduction.

If you’re curious about how this stacks up against platforms like Heroku, Render or Railway, I can post a cost-comparison table.

2. We track CPU usage in real-time across all workloads and maintain a global usage map.

3. Idle CPU from any app/node becomes available for re-purchase by other workloads in the same resource plan.

4. CPU limits can be adjusted on the fly without restarts, enabling real-time response to changing load.

If anyone wants to dive into topics like threshold algorithms, node assignment heuristics, or Kubernetes API interactions - I'm happy to dig into that.

Traditional platforms still charge per app, even if each app barely touches the CPU.

We redesigned scheduling: CPU is dynamically shared across your workloads based on real demand. You pay once for the resource, rather than multiple times for idle capacity.

I'm happy to discuss technical details, scheduler design, and the challenges we encountered along the way.

Comments URL: https://news.ycombinator.com/item?id=45882422

Points: 1

# Comments: 3