ktaraszk

Still free hosting

They won't let you. It's part of their business to keep you locked in.

Yes, it is, but why or what for?

The routing layer being down while workers/data services stay up is such a specific failure mode. Usually means the load balancers or edge routing got corrupted somehow, not the actual compute infrastructure.

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.

Yeah, if Heroku's cert rotation depends on Google's CA and it tried to renew during the outage window, that'd definitely cause problems. The 8-hour ETA is rough. This is why multi-CA fallback configs exist, but most platforms don't bother until they get burned by something like this. Worth checking if your apps are actually affected or if it's just the dashboard/API having issues.

The fact that your database is reachable but the app isn't after restart points to the routing layer being toast. If you can ssh into the dyno or check logs, look for anything related to the router handshake timing out. Usually when deploys work but traffic doesn't route, it's something between the load balancer and your instances.

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.

The status page lag is the worst part. Hard to debug when you're questioning whether it's your config or their infrastructure. At least when multiple providers go down at once you know it's not just you going insane.

The CA outage is hitting a lot of services, but yeah, Heroku's been on a slow decline since the Salesforce acquisition. Free tier killed, pricing creep, stagnant innovation. Even when it's not their fault, you start wondering if it's worth the risk of being on a platform that feels like it's in maintenance mode.

I've been watching this thread closely. We built miget (https://miget.com/) specifically because of these pain points. The Heroku-style DX without the eye-watering bills or corporate neglect.

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 enterprise communication breakdown is rough. We built miget (https://miget.com/) partly because we kept hearing stories like ojame's - long-time Heroku users stuck between expensive renewals and migration risk.

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.

We built miget.com specifically for cases like this. Free tier (no card required) with 256MB RAM should handle Spring Boot apps fine for teaching purposes. It's much simpler than Azure but still supports any JVM app. If your students need more resources later, hobby plans start at $5/mo. Happy to help get your course set up if you want to try it out.

The AI-assisted provisioning part is wild. That setup would've taken days just a few years ago.

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."

This exactly. The tech migration part is usually straightforward (Buildpacks and Procfiles work mostly the same across platforms), but the harder question is "how do we avoid this situation again?"

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.

I used Heroku until 2023 too. That "operational excellence" line felt like a euphemism for "we're done here."

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 "on life support" analogy is spot on. We built miget (https://miget.com) specifically because of this pattern, watching platforms slowly sunset while users scramble to migrate under pressure.

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.

Yes, have you seen miget.com by any chance? You can start with the free tier, and can have a backend with a database for free (256Mi plan). If you need more, just upgrade. They redefined cloud billing. Worth checking.

Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os

and you should be good

Interesting. Is this going to be integrated with Jira, ClickUp, etc?

A couple of questions I expect here (based on similar discussions in other channels):

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.

A quick example of why this matters for devs & startups: imagine you’ve got 5 small apps each using 0.3 CPU most of the time. In most PaaS you’d pay for 5 separate instances. On Miget you pay for one resource plan and those apps share the CPU dynamically - result: ~75% cost reduction.

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

Here’s a bit more detail on how the scheduler works under the hood: 1. Each application still runs on its own Kubernetes node to guarantee isolation (so noisy-neighbor issues are eliminated).

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.

Hey, thanks for the comment - you're right.

It’s pronounced /ˈmɪgɛt/ – like it’s spelled, with a hard “g”. No relation to “midget”, no offense intended.

Thanks again for pointing it out!

Great question, let me clarify:

At Miget, you always start with a fixed plan: say, 2 vCPUs and 4GB RAM. That’s your hard cap — you can deploy as many apps as you want within that limit. We support autoscaling within your plan, meaning your workloads can scale horizontally as long as you stay within your allocated resources.

We intentionally dislike mandatory usage-based billing because it often leads to unpredictable costs. That’s why we made it optional.

For advanced users or production workloads that do want to scale beyond their plan, we’re working on opt-in usage-based billing. But only if you explicitly enable it. That way, you get a stable, predictable base, and optional elasticity if your needs grow.

So the core idea remains: No surprises. You’re in control.

Hey HN,

After years of pain using platforms like Heroku, Render, Fly, and Railway, we decided to build our own. It’s called Miget, and it rethinks both the developer experience and the economics of deployment.

Most PaaS platforms tax you per app, per dyno, per background worker, per staging environment, etc. Or worse—usage-based billing that’s impossible to predict (hi Railway).

We flipped the model: You choose a plan (with fixed CPU/RAM), deploy as many apps as you want inside it—frontend, backend, workers, databases-and that’s your bill. No surprises, no meter running in the background. Think VPS simplicity with modern PaaS DX.

Under the hood:

- Fair Scheduler based on CFS principles (like a smarter VPS) - Kubernetes + microVMs (CloudHypervisor) - Cloud Native Buildpacks or Docker builds - Built-in IPv6, SSH, full API (coming soon) - Transparent billing via Polar.sh - Usage-based billing opt-in (coming soon)

Built for hackers, indie devs, startups building their MVPs or just tired of being nickel-and-dimed.

Clarification on the name: It’s Miget, pronounced like “widget.” Not “midget.” No relation, no offense intended-just a short, punchy name.

Would love your thoughts, feedback, roasting, or questions. Live now at https://miget.com