[HN Gopher] Replacing a $3000/mo Heroku bill with a $55/mo server
___________________________________________________________________
Replacing a $3000/mo Heroku bill with a $55/mo server
Author : jryio
Score : 288 points
Date : 2025-10-21 20:28 UTC (2 hours ago)
(HTM) web link (disco.cloud)
(TXT) w3m dump (disco.cloud)
| gregsadetsky wrote:
| Heya, Disco is the open source PaaS I've been working on with my
| friend Antoine Leclair.
|
| Lots of conversation & discussion about self-hosting / cloud
| exits these days (pros, cons, etc.) Happy to engage :-)
|
| Cheers!
| bstsb wrote:
| what does this service offer over an established tool like
| Coolify? currently hosting most of my services on a cheap
| Hetzner VPS so i'm interested what Disco has to offer
| alberth wrote:
| Or Dokku, Dokploy or CapRover
|
| Would be great to have a comparison on the main page of Disco
| odie5533 wrote:
| There's quite a few now. Coolify, Dokku, CapRover, Kamal.
| gregsadetsky wrote:
| Coolify and other self-hosting options such as Kamal are
| great. We're all in the same boat!
|
| I'd say the main differences is that we 1) we offer a more
| streamlined CLI and UI rather than offering extensive
| app/installation options 2) have an api-key based system that
| lets team members collaborate without having to manage ssh
| access/keys.
|
| Generally speaking, I'd say our approach and tooling/UX tends
| to be more functional/pragmatic (like Heroku) than one with
| every possible option.
| Onavo wrote:
| There's also Canine and Kubero
|
| https://news.ycombinator.com/item?id=44292103
|
| https://news.ycombinator.com/item?id=44873057
| martinald wrote:
| Just to be aware when you say "Even with all 6 environments and
| other projects running, the server's resource usage remained
| low. The average CPU load stayed under 10%, and memory usage
| sat at just ~14 GB of the available 32 GB."
|
| The load average in htop is actually per CPU core. So if you
| have 8 CPU cores like in your screenshot, a load average of 0.1
| is actually 1.25% (10% / 8) of total CPU capacity - even better
| :).
|
| Cool blog! I've been having so much success with this type of
| pattern!
| gregsadetsky wrote:
| Sharp eye! Thanks. Fixed
| tempest_ wrote:
| The cloud has made people forget how far you can get with a
| single machine.
|
| Hosting staging envs in pricey cloud envs seems crazy to me but I
| understand why you would want to because modern clouds can have a
| lot of moving parts.
| odie5533 wrote:
| Fully replicating prod is helpful. Saves time since deployment
| is similar and does a better test of what prod will be.
| teaearlgraycold wrote:
| Completely agree. It's not a staging server if it's hosted on
| a different platform.
| odie5533 wrote:
| I think OP is using these less as staging and more as dev
| environments for individual developers. That seems like a
| great use of a single server to me.
|
| I'd still like a staging + prod, but keeping the dev
| environments on a separate beefy server seems smart.
| ricketycricket wrote:
| I've been using a development server for about 9 years
| and the best thing I ever did was move to a machine with
| a low-power Xeon D for a time. It made development
| painful enough that I quickly fixed the performance
| issues I was able to overlook on more powerful hardware.
| I recommend it, even just as an exercise.
| hamdingers wrote:
| The "platform" software runs on is just other software. If
| your prod environment is managed kubernetes then you don't
| lose much if your staging environment is self-hosted
| kubernetes.
| odie5533 wrote:
| Load balancers, IAM roles, kubernetes upgrades, postgres
| upgrades, security settings, DNS records, http routes...
| there's a lot that can go wrong and makes it useful to
| have a staging environment.
| j45 wrote:
| Cloud often has everyone thinking it's still 2008.
| tempest_ wrote:
| With some obvious exceptions there isnt much you cant run on
| a 200 Core machine wrt web services.
| rikafurude21 wrote:
| The cloud has made people afraid of linux servers. The markup
| is essentially just the price business has to pay because of
| developer insecurity. The irony is that self hosting is
| relatively simple, and alot of fun. Personally never got the
| appeal of Heroku, Vercel and similar, because theres nothing
| better than spinning up a server and setting it up from
| scratch. Every developer should try it.
| agumonkey wrote:
| my take is that it's fun up until there's just enough
| brittleness and chaos.. too many instance of the same thing
| but with too many env variables setup by hand and then fuzzy
| bug starts to pile up
| daemonologist wrote:
| I dunno, the cloud has mostly made me afraid of the cloud.
| You can bury yourself in towering complexity _so_ easily on
| AWS. (The highly managed stuff like Vercel I don 't have much
| experience with, so maybe it's different.)
| ygouzerh wrote:
| I will recommend to try GCP or Azure, the complexity is
| lower there! AWS is great for big corporate that needs a
| lot of lego pieces to do their own custom setup. At the
| contrario, GCP and Azure solutions are often more bundled.
| tempest_ wrote:
| It is way more than that though.
|
| It offloads things like - Power Usage - Colo Costs -
| Networking (a big one) - Storage (SSD wear / HDD pools) - etc
|
| It is a long list but what doesnt allow you do it make trade
| offs like spending way less but accept downtime if your
| switch dies etc etc.
|
| For a staging env these are things you might want to do.
| jampekka wrote:
| > The irony is that self hosting is relatively simple, and
| alot of fun. Personally never got the appeal of Heroku,
| Vercel and similar, because theres nothing better than
| spinning up a server and setting it up from scratch.
|
| It's fun the first time, but becomes an annoying faff when it
| has to be repeated constantly.
|
| In Heroku, Vercel and similar you git push and you're
| running. On a linux server you set up the OS, the server
| authentication, the application itself, the systemctl jobs,
| the reverse proxy, the code deployment, the ssl key
| management, the monitoring etc etc.
|
| I still do prefer a linux server due to the flexibility, but
| the UX could be a lot better.
| YouAreWRONGtoo wrote:
| [flagged]
| dang wrote:
| Can you please edit out swipes, putdowns, name-calling,
| etc., from your HN posts? It's not what this site is for,
| and destroys what it is for.
|
| This is in the site guidelines:
| https://news.ycombinator.com/newsguidelines.html.
| tbrownaw wrote:
| And all of that takes, what, a week? As a one time thing?
| jcynix wrote:
| Takes less than a day, because most of the stuff is
| scriptable. And for a simple compute node setup at
| Hetzner (I.e. no bare metal, but just a VM) it takes me
| less than half an hour.
| teekert wrote:
| I use NixOS and a lot of it is in a single file. I just saw
| some ansible coming by here, and although I have no
| experience with it, it looked a lot simpler than Nix (for
| someone from the old Linux world, like me... eventhough Nix
| is, looking through your eyelashes, just a pile of
| key/value pairs).
| sokoloff wrote:
| > the price business has to pay because of developer
| insecurity
|
| Is it mostly _developer_ insecurity, or mostly _tech
| leadership_ insecurity?
| fragmede wrote:
| Never got the appeal of having someone else do something for
| you, and giving them money, in exchange for goods and
| services? Vercel is easy. You pay them to make it easy. When
| you're just getting started, you start on easy mode before
| you jump into the deep end of the pool. Everybody's got a
| different cup of tea, and some like it hot and others like it
| cold.
| rikafurude21 wrote:
| Sure I love having someone else do work for me and paying
| them for that, the question is if that work is worth a 50x
| markup.
| fragmede wrote:
| Yeah, but then we're just haggling. If you know how to
| change the belt on your car and already have the tools,
| it's different from when you're stranded with no tools
| and no garage and no belt.
| rikafurude21 wrote:
| If you're a mechanic you're supposed to know how to
| change the belt on your car. It would be insane if you
| write code and work with computers for a living but you
| dont know how to set up a web server.
| everyone wrote:
| It would be insane if you write code and work with
| computers for a living but you dont know how to write a
| game engine in assembly.
| sgarland wrote:
| Installing a web server is in no way the same as writing
| a game engine, let alone in assembly, and I think you
| know that.
| auggierose wrote:
| I am pretty sure I know much more about code than you do,
| and at the same time you probably know much more about
| web servers and sysadmin than I do. I don't mind if it
| stays like that. And I am saying this having programmed
| my own web server in Java about 25 years ago.
| alwa wrote:
| Flour, salt, and water are exceedingly cheap. I have to
| imagine the loaf of bread I buy from my baker reflects
| considerably more than a 50x markup compared to baking my
| own.
|
| It's a lot cheaper than me learning to bake as well as he
| does--not to mention dedicating the time every day to get
| my daily bread--and I'll _never_ need bread on the kind
| of scale that would make it worth my time to do so.
| mediaman wrote:
| Bread is a great example! You can buy a loaf for $3-4. It
| is _not_ a 50x markup. Like growing your own veggies,
| baking bread is for fun, not for economics.
|
| But the cloud is different. None of the financial scale
| benefits are passed on to you. You save serious money
| running it in-house. The arguments around scale have no
| validity for the vast, vast majority of use cases.
|
| Vercel isn't selling bread: they're selling a fancy steak
| dinner, and yes, you can make steak at home for much
| less, and if you eat fancy steak dinners at fancy
| restaurants every night you're going to go broke.
|
| So the key is to understand whether your vendors are
| selling you bread, or a fancy steak dinner, and to not
| make the mistake of getting the two confused.
| MangoCoffee wrote:
| The cloud has made people forget that the internet is
| decentralized.
| jamestimmins wrote:
| This could be the premise for a fun project based infra
| learning site.
|
| You get X resources in the cloud and know that a certain
| request/load profile will run against it. You have to configure
| things to handle that load, and are scored against other
| people.
| YouAreWRONGtoo wrote:
| All it means is that the cloud doesn't work like a power
| socket, which was the whole point of it.
|
| Things like Lambda do fit in this model, but they are too
| inefficient to model every workload.
|
| Amazon lacks vision.
| altcognito wrote:
| The weird thing is the relationship between developer costs and
| operations costs. For startups that pay salaries, $3000 a month
| is a pittance!*
|
| * The big caveat: If you don't incur the exact same devops
| costs that would have happened with a linux instance.
|
| Many tools (containers in particular) have cropped up that have
| made things like quick, redundant deployment pretty
| straightforward and cheap.
| andersa wrote:
| The best part is when you start with a $3000/month cloud bill
| during development and finally realize that hosting the
| production instance this way would actually cost $300k/month,
| but now it's too late to change it quickly.
| jeroenhd wrote:
| Teaching a whole bunch of developers some cloud basics and
| having a few cloud people around is relatively cheap for quite
| a while. Plus, having test/staging/prod on similar
| configurations will help catch mistakes earlier. None of that
| "localstack runs just fine but it turns out Amazon SES isn't
| available in region antartica-east-1". Then, eventually, you
| pay a couple people's wages extra in cloud bills, and leaving
| the cloud becomes profitable.
|
| Cloud isn't worth it until suddenly it is because you can't
| deploy your own servers fast enough, and then it's worth it
| until it exceeds the price of a solid infrastructure team and
| hardware. There's a curve to how much you're saving by throwing
| everything in the cloud.
| nine_k wrote:
| Deploying to your private cloud requires basically the same
| skills. Containers, k8s or whatnot, S3, etc. Operating a
| large DB on bare metal is different from using a managed DB
| like Aurora, bit for developers, the difference is hardly
| visible.
| nimbius wrote:
| you can literally buy a used dell desktop that matches the spec
| for hetzner (8 core, 32 gigs of ram) for under 500 USD. Why
| wouldnt you just do that?
|
| As cloud marches on it continues to seem like a grift.
| sodality2 wrote:
| Do you plan on keeping it in your home? At that point I'd be
| worried about ISP networking or power guarantees unless you
| plan on upgrading to business rates for both. If you mean
| colo, well, if you're sure you'll be using it in X years,
| it's worth it, but the flexibility of month-to-month might be
| preferable.
| SchemaLoad wrote:
| Because that used desktop is subject to power outages,
| internet outages, the cleaners unplugging it, etc.
| Datacenters have redundancy on everything.
| noosphr wrote:
| The cloud was a good deal in 2006 when the smallest aws machine
| was about the size of a ok dev desktop and took over two years
| of renting to justify buying the physical machine outright.
|
| Today the smallest, and even large, aws machines are a joke,
| comparable to a mobile phone from 15 years ago to a terrible
| laptop today, and take about three to six months to in rent as
| buying the hardware outright.
|
| If you're on the cloud without getting 75% discount you will
| save money and headcount by doing everything on prem.
| adgjlsfhk1 wrote:
| also how far you can get with a single machine has changed
| massively in the past 15 years. 15 years ago a (really beefy)
| single machine meant 8 cores with 256GB ram and a couple TB of
| storage. Now a single machine can be 256 cores on 8TB of ram
| and a PB of storage.
| zachrip wrote:
| Heroku's pricing model made me shy away even from using them for
| small stuff. Why get comfortable on a stack that disincentivizes
| success?
| j45 wrote:
| The kind of headline that is worth learning more about.
|
| Dokku can be an option if needed to maintain heroku endpoints.
| nine_k wrote:
| Nice! Way to go for non-prod environments. (For prod you'd need
| some redundancy at least.)
|
| Quick question: how long would it take to provision and set up
| another server if this one dies?
| sarchertech wrote:
| I bet less time than it takes AWS to recover from a significant
| event. And I bet it happens less often too.
| odie5533 wrote:
| Ideally these things should go in an Ansible playbook or
| whatever people are using these days to manage their pets.
| nine_k wrote:
| I mean the availability of the hardware. It's a dedicated
| server, AFAICT.
| odie5533 wrote:
| At $55/mo, they could buy another server in another state.
| ygouzerh wrote:
| One thing however to note, is that by having a different non-
| prod and prod environment, it will be possible to test only the
| application, and not the infra.
|
| Which means, that if they want to test what it will look like
| running in cloud for prod, they are going to either need a pre-
| prod environment or go yolo
| gregsadetsky wrote:
| The longest is to adapt your app to a Dockerfile-based
| deployment, if it isn't already containerized. We have examples
| for most languages - for Flask, for example, the whole file is
| 10 lines long [0]
|
| But to provision a new server, as these are "stateless" (per 12
| Factor) servers, it's just 1) get a VPS 2) install Docker+Disco
| using our curl|sh install script 3) authorize github 4) deploy
| a "project" (what we call an app), setting the env vars.
|
| All in all ~10 minutes for a new machine.
|
| [0] https://github.com/gregsadetsky/example-flask-
| site/blob/main...
| zachlatta wrote:
| We've had a similar experience at Hack Club, the nonprofit I run
| that helps high schoolers get into coding and electronics.
|
| We used to be on Heroku and the cost wasn't just the high monthly
| bill - it was asking "is this little utility app I just wrote
| really worth paying $15/month to host?" before working on it.
|
| This year we moved to a self-hosted setup on Coolify and have
| about 300 services running on a single server for $300/month on
| Hetzner. For the most part, it's been great and let us ship a lot
| more code!
|
| My biggest realization is that for an organization like us, we
| really only need 99% uptime on most of our services (not 99.99%).
| Most developer tools are around helping you reach 99.99% uptime.
| When you realize you only need 99%, the world opens up.
|
| Disco looks really cool and I'm excited to check it out!
| gregsadetsky wrote:
| Cheers, let me know if you do / hop onto our Discord for any
| questions.
|
| We know of two similar cases: a bootcamp/dev school in Puerto
| Rico that lets its students deploy all of their final projects
| to a single VPS, and a Raspberry Pi that we've set up at the
| Recurse Center [0] which is used to host (double checking now)
| ~75 web projects. On a single Pi!
|
| [0] https://www.recurse.com/
| IshKebab wrote:
| 300 services?? What do they all do?
| radiator wrote:
| And if you really needed 99.99%, you would be wise to avoid the
| hyperscalers: see AWS' recent multi-hour long outage.
| bstsb wrote:
| i'd be interested what the load is like on that CCX33 server -
| i've got a lower-spec VPS from Hetzner and even from there I'm
| only using about 25%-30% CPU/RAM with a moderate load
| odie5533 wrote:
| From the article:
|
| > Even with all 6 environments and other projects running, the
| server's resource usage remained low. The average CPU load
| stayed under 10%, and memory usage sat at just ~14 GB of the
| available 32 GB.
| masterj wrote:
| Title seems slightly exaggerated since by my reading there was no
| actual $3000 / month bill? Still a great use-case
|
| This seems like a good idea to have plentiful dev environments
| and avoid a bad pricing model. If your production instance is
| still on Heroku, you might still want a staging environment on
| Heroku since a Hetzner server and your production instance might
| have subtle differences.
| ed_elliott_asc wrote:
| Do they really need a full mirror of production?
| zdragnar wrote:
| Every time I've worked somewhere without one, we've wanted it
| and wasted more developer hours than the cost of having it
| trying to reproduce issues while working around the differences
| in the environments.
| SFHacker21 wrote:
| oh good point
| killingtime74 wrote:
| Hetzner cloud has instances in US, which could work since they
| don't need the stability of dedicated for staging/dev.
| turtlebits wrote:
| It sounds more like poor choices. 6 staging environments sounds a
| bit overkill.
|
| If you can fit them all on a 4 cpu / 32gb machine, you can easily
| forgo them and run the stack locally on a dev machine. IME
| staging environments are generally snowflakes that are hard to
| stand up (no automation).
|
| $500/month each is a gross overpayment.
| viraptor wrote:
| > you can easily forgo them and run the stack locally
|
| Not if you're running with external resources of specific type,
| or want to share the ongoing work with others. Or need to setup
| 6 different projects with 3 different databases at the same
| time. It really depends on your setup and way of working.
| Sometimes you can do local staging easily, sometimes it's going
| to be a lot of pain.
| swanson wrote:
| I guess I'm not quite understanding why you need six staging
| servers provisioned at $500 a pop? And if you need that because
| you have a large team...what percentage of your engineering spend
| is $3000 vs $100k+/yr salaries?
|
| Especially when I got look at the site in question (idealist.org)
| and it seems to be a pretty boring job board product.
| odie5533 wrote:
| From what I read, they're using them as dev environments. Like
| running many services at once for a single developer to tie
| into. That's why they wanted multiple ones, one for each dev.
| ygouzerh wrote:
| Yes, everyone forget to compute man-days in the cost
| calculation
| gregsadetsky wrote:
| 6 staging servers: main, dev, and any branches that you want to
| let other (non tech people) QA.
|
| As for the staging servers, for each deployment, it was a mix
| of Performance-M dynos, multiple Standard dynos, RabbitMQ, a
| database large enough, etc. - it adds up quickly.
|
| Finally, Idealist serves ~100k users per day - behind the
| product is a lot of boring tech that makes it reliable & fast.
| :-)
| hinkley wrote:
| > The Real Insight: Staging Became a Free Commodity
|
| Not free, it became a productivity boost.
|
| You now have a $35k annual budget for the maintenance, other
| overhead, and lost productivity. What do you spend it on?
|
| > The team also took on responsibility for server monitoring,
| security updates, and handling any infrastructure issues
| themselves
|
| For a place that's paying devs $150k a year that might math out.
| It absolutely does not for places paying devs $250k+ a year.
|
| One of the great frustrations of my mid career is how often
| people tried to bargain for more speed by throwing developers at
| my already late project when what would have actually helped
| almost immediately was more hardware and tooling. But that didn't
| build my boss' or his bosses' empires. Don't give me a $150k
| employee to train, give me $30k in servers.
|
| Absolutely no surprise at all when devs were complicit with Cloud
| migrations because now you could ask forgiveness instead of
| permission for more hardware.
| ygouzerh wrote:
| Single server is very cheap for hobbyist.
|
| Just something to consider if you are in a professional
| environment before switching your entire infra: maintenance cost
| is expensive. I strongly suggest to throw man-days in your cost
| calculation.
|
| To prevent security vulnerabilities, the team will need to write
| some playbooks to auto-update regularly your machine, hoping for
| no breaking changes. Or instead write a pipeline for immutable OS
| images updates. And it often mean testing on an additional canary
| VM first.
|
| Scaling up the VM from a compute point of view is not that
| straightforward as well, and will require depending of the
| provider either downtime or to migrate the entire deployments to
| a new instance.
|
| Scaling from a disk size point of view, you will need to play
| with filesystems.
|
| And depending on the setup you are using, you might have to
| manage lets encrypt, authentication and authorization, secrets
| vaults, etc (here at least Disco manages the SSL certs for you)
| ebiester wrote:
| If you are large enough, you will need an ops team to manage
| allowing your developers to write terraform and manage AWS
| costs already.
|
| If you are small enough, you are not going to be truly affected
| by downtime. If you are just a little bigger, a single hot
| spare is going to be sufficient.
|
| The place where you get dinged is heavy growth in personnel and
| bandwidth. You end up needing to solve CPU bound activities
| quicker because it hurts the whole system. You need to start
| thinking about sticky round robin load balancing and other fun
| pieces.
|
| This is where the cloud can allow you to trade money for
| velocity. Eventually, though, you will need to pay up.
|
| That said, the average SaaS can go a long way with a single
| server per product.
| bigstrat2003 wrote:
| > I strongly suggest to throw man-days in your cost
| calculation.
|
| Only if those man-days actually incur a marginal cost. If it's
| just employees you already have spending their time on things,
| then it's not worth factoring in because it's a cost you pay
| regardless.
| Tiberium wrote:
| The situation is interesting, and self-hosting is indeed a very
| nice solution often. However, I wanted to comment on the article
| itself - it seems to be very heavily AI-edited. Anyone who has
| spent time with LLMs will easily see it. But even that's not the
| issue; the main issue is that the article is basically a
| marketing piece.
|
| For example, the "Bridging the Gap: Why Not Just Docker Compose?"
| section is a 1:1 copy of the points in the "Powerful simplicity"
| on the landing page - https://disco.cloud/
|
| And this blog post is the (only) case study that they showcase on
| their main page.
| AstroBen wrote:
| heh my first instinct was to go see how they're making money.
| Guess that's coming soon
| gregsadetsky wrote:
| You're absolutely right! Here are some three points why:
|
| - ...
|
| I'm kidding :-)
|
| Our library is open source, and we're very happy and proud that
| Idealist is using us to save a bit of cash. Is it marketing if
| you're proud of your work? :-) Cheers
| colechristensen wrote:
| There's a tone issue.
|
| Marketing should be marketing and clearly so. Tech blogs are
| about sharing information with the community (Netflix Tech
| blog is a good example) NOT selling something. Marketing
| masquerading as a tech blog is offputting to a lot of people.
| People don't like being fooled with embedded advertising and
| putting ad copy into such pieces is at best annoying.
|
| https://netflixtechblog.com/
| fragmede wrote:
| Nah, people are stupid. Including me. It's all marketing.
| Netflix's tech blog is marketing to engineers to want to go
| work there and to promote their product. If you want to see
| things though the lense that all advertising is bad, you'll
| make your life miserable because it's all advertising in
| one way or another.
| colechristensen wrote:
| What you've done is taken something I've written,
| redefined a core term in a way I obviously didn't mean,
| and then told me I'm wrong because of your redefinition.
| fragmede wrote:
| When you put it that way, you make me sound like an ass.
| Is that how I'm coming across? What did I redefine? I'm
| refuting the fairytale where some content is pure and
| untainted by marketing. Netflix writes posts that make
| engineers want to work there and people think, "hey,
| that's smart!" That's marketing.
| ashirviskas wrote:
| I think a big difference is when someone is pretending to
| be all about something else and tries to sneakily market
| to you. One thing is getting a free water bottle with an
| ad, another thing is when someone is inviting you to a
| "party" with free food and drinks and it turns out to be
| a MLM "party".
|
| Netflix is giving away free water bottles (I hate them,
| but I use their fast.com super often to test the speeds),
| another is pretending to be a blog post, but actually
| being an ad (if that was the case here). You just feel
| lied to. You cannot take anything seriously you read
| there, as it will probably be super biased and you cannot
| get your time back now.
| teiferer wrote:
| Is it? Was this, your HN comment, marketing?
|
| Mine isn't, unless you make the meaning of that term so
| broad that it essentially lost any meaningful meaning.
| (Intentionally meta.)
| fragmede wrote:
| That's the problem with framing everything that way. This
| HN comment is marketing for my brand, my username, I sell
| t-shirts on my website! That's not why I'm commenting
| here, but the term is that broad because we're using it
| colloquially. It's a human psychology thing that I get
| entrapped into too. Calling it out doesn't make it not
| work. When you use the lens of marketing, your comment is
| marketing that you are not marketing, which is a specific
| category and advertising profile to be filed away in a
| database somewhere, if we go to the theoretical extremes.
| cirrus3 wrote:
| This isn't the first time an article is also marketing.
| Besides, what is wrong with marketing something via a use case
| article? This is a fairly tame example of it and I found it an
| interesting and useful read, knowing full well it was also
| marketing.
| jdprgm wrote:
| It's funny they have this marketing blog post based on
| competing on price yet don't disclose any of their pricing on
| their site only a schedule a meeting which is just about the
| biggest RED FLAG on pricing there is.
| gregsadetsky wrote:
| Our library is open source, the price is 0!! :-) Haha
|
| We're actually mostly talking to people (that "schedule a
| meeting") to see how we can help them migrate their stuff
| away (from Heroku, Vercel, etc.)
|
| But we're not sure of the pricing model yet - probably
| Entreprise features like Gitlab does, while remaining open
| source. It's a tough(er) balance than running a hosted
| service where you can "just" (over)charge people.
| tasuki wrote:
| > But even that's not the issue; the main issue is that the
| article is basically a marketing piece.
|
| Why is that an issue? Is it forbidden by HN guidelines? Or
| would you like all marketing to be marked as such? Which
| articles _aren't_ marketing, one way or another?
| speedgoose wrote:
| Looking at the htop screenshot, I notice the lack of swap. You
| may want to enable earlyoom, so your whole server doesn't go down
| when a service goes bananas. The Linux Kernel OOM killer is often
| a bit too late to trigger.
|
| You can also enable zram to compress ram, so you can over-
| provision like the pros'. A lot of long-running software leaks
| memory that compresses pretty well.
|
| Here is how I do it on my Hetzner bare-metal servers using
| Ansible:
| https://gist.github.com/fungiboletus/794a265cc186e79cd5eb2fe...
| It also works on VMs.
| cactusplant7374 wrote:
| What's the performance hit from compressing ram?
| speedgoose wrote:
| I haven't scientifically measured, but you don't compress the
| whole ram. It is more about reserving a part of the ram to
| have very fast swap.
|
| For an algorithm using the whole memory, that's a terrible
| idea.
| sokoloff wrote:
| > It is more about reserving a part of the ram to have very
| fast swap.
|
| I understand all of those words, but none of the meaning.
| Why would I reserve RAM in order to put fast swap on it?
| vlovich123 wrote:
| Swap to disk involves a relatively small pipe (usually
| 10x smaller than RAM). So instead of paying the cost to
| page out to disk immediately, you create compressed pages
| and store that in a dedicated RAM region for compressed
| swap.
|
| This has a number of benefits: in practice more "active"
| space is freed up as unused pages are compressed and
| often compressible. Often times that can be freed
| application memory that is reserved within application
| space but in the free space of the allocator, especially
| if that allocator zeroes it those pages in the
| background, but even active application memory (eg if you
| have a browser a lot of the memory is probably duplicated
| many times across processes). So for a usually invisible
| cost you free up more system RAM. Additionally, the
| overhead of the swap is typically not much more than a
| memcpy even compressed which means that you get dedup and
| if you compressed erroneously (data still needed) paging
| it back in is relatively cheap.
|
| It also plays really well with disk swap since the least
| frequently used pages of that compressed swap can be
| flushed to disk leaving more space in the compressed RAM
| region for additional pages. And since you're flushing
| retrieving compressed pages from disk you're reducing
| writes on an SSD (longevity) and reducing read/write
| volume (less overhead than naiive direct swap to disk).
|
| Basically if you think of it as tiered memory, you've got
| registers, l1 cache, l2 cache, l3 cache, normal RAM,
| compressed swap RAM, disk swap - it's an extra interim
| tier that makes the system more efficient.
| YouAreWRONGtoo wrote:
| It's sometimes not a hit, because CPUs have caches and memory
| bandwidth is the limiting factor.
| waynesonfire wrote:
| > zram, formerly called compcache, is a Linux kernel module
| for creating a compressed block device in RAM, i.e. a RAM
| disk with on-the-fly disk compression. The block device
| created with zram can then be used for swap or as a general-
| purpose RAM disk
|
| To clarify OP's represention of the tool, it compresses swap
| space not resident ram. Outside of niche use-cases,
| compressing swap has overall little utility.
| aidenn0 wrote:
| Depends on the algorithm (and how much CPU is in use); if you
| have a spare CPU, the faster algorithms can more-or-less keep
| up with your memory bandwidth, making the overhead
| negligible.
|
| And of course the overhead is zero when you don't page-out to
| swap.
| levkk wrote:
| Yeah, no way. As soon as you hit swap, _most_ apps are going to
| have a bad, bad time. This is well known, so much so that all
| EC2 instances in AWS disable it by default. Sure, they want to
| sell you more RAM, but it's also just true that swap doesn't
| work for today's expectations.
|
| Maybe back in the 90s, it was okay to wait 2-3 seconds for a
| button click, but today we just assume the thing is dead and
| reboot.
| gchamonlive wrote:
| How programs use ram also changed from the 90s. Back then
| they were written targeting machines that they knew would
| have a hard time fitting all their data in memory, so hitting
| swap wouldn't hurt perceived performance too drastically
| since many operations were already optimized to balance data
| load between memory and disk.
|
| Nowadays when a program hits swap it's not going to fallback
| to a different memory usage profile that prioritises disk
| access. It's going to use swap as if it were actual ram, so
| you get to see the program choking the entire system.
| winrid wrote:
| Exactly. Nowadays, most web services are run in a GC'ed
| runtime. That VM will walk pointers all over the place and
| reach into swap all the time.
| cogman10 wrote:
| Depends entirely on the runtime.
|
| If your GC is a moving collector, then absolutely this is
| something to watch out for.
|
| There are, however, a number of runtimes that will leave
| memory in place. They are effectively just calling
| `malloc` for the objects and `free` when the GC algorithm
| detects an object is dead.
|
| Go, the CLR, Ruby, Python, Swift, and I think node(?) all
| fit in this category. The JVM has a moving collector.
| zoeysmithe wrote:
| This is really interesting and I've never really heard
| about this. What is going on with the kernel team then? Are
| they just going to keep swap as-is for backwards
| compatibility then everyone else just disables it?
| henryfjordan wrote:
| Does HDD vs SSD matter at all these days? I can think of
| certain caching use-cases where swapping to an SSD might make
| sense, if the access patterns were "bursty" to certain keys
| in the cache
| winrid wrote:
| It's still extremely slow and can cause very unpredictable
| performance. I have swap setup with swappiness=1 on some
| boxes, but I wouldn't generally recommend it.
| LaurensBER wrote:
| The beauty of ZRAM is that on any modern-ish CPU it's
| surprisingly fast. We're talking 2-3 ms instead of 2-3
| seconds ;)
|
| I regularly use it on my Snapdragon 870 tablet (not exactly a
| top of the line CPU) to prevent OOM crashes (it's running an
| ancient kernel and the Android OOM killer basically crashes
| the whole thing) when running a load of tabs in Brave and a
| Linux environment (through Tmux) at the same time.
|
| ZRAM won't save you if you do actually need to store and
| actively use more than the physical memory but if 60% of your
| physical memory is not actively used (think background tabs
| or servers that are running but not taking requests) it
| absolutely does wonders!
|
| On most (web) app servers I happily leave it enabled to
| handle temporary spikes, memory leaks or applications that
| load a whole bunch of resources that they never ever use.
|
| I'm also running it on my Kubernetes cluster. It allows me to
| set reasonable strict memory limits while still having the
| certainty that Pods can handle (short) spikes above my limit.
| bayindirh wrote:
| This is a wrong belief because a) SSDs make swap almost
| invisible, so you can have that escape ramp if something goes
| wrong b) SWAP space is not solely an escape ramp which RAM
| overflows into anymore.
|
| In the age of microservices and cattle servers,
| reboot/reinstall might be cheap, but in the long run it is
| not. A long running server, albeit being cattle, is always a
| better solution because esp. with some excess RAM, the server
| "warms up" with all hot data cached and will be a low latency
| unit in your fleet, given you pay the required attention to
| your software development and service configuration.
|
| Secondly, Kernel swaps out unused pages to SWAP, relieving
| pressure from RAM. So, SWAP is often used even if you fill 1%
| of your RAM. This allows for more hot data to be cached,
| allowing better resource utilization and performance in the
| long run.
|
| So, _eff it, we ball_ is never a good system administration
| strategy. Even if everything is ephemeral and can be rebooted
| in three seconds.
|
| Sure, some things like Kubernetes forces "no SWAP, period"
| policies because it kills pods when pressure exceeds some
| value, but for more traditional setups, it's still valuable.
| gchamonlive wrote:
| > SSDs make swap almost invisible
|
| It doesn't. SSDs came a long way but so did memory dies and
| buses, and with that the way programs work also changed as
| more and more they are able to fit their stacks and heaps
| on memory more often than not.
|
| I have had a problem with shellcheck that for some reason
| eats up all my ram when I open I believe .zshrc and trust
| me, it's _not invisible_. The system crawls to a halt.
| bayindirh wrote:
| It depends on the SSD, I may say.
|
| If we're talking about SATA SSDs which top at 600MBps,
| then yes, an aggressive application can make itself
| known. However, if you have a modern NVMe, esp. a 4x4 one
| like Samsung 9x0 series or if you're using a Mac, I bet
| you'll notice the problem much later, if ever. Remember
| the SSD trashing problem on M1 Macs? People never noticed
| that system used SWAP that heavily and trashed the SSD on
| board.
|
| Then, if you're using a server with a couple of SAS or
| NVMe SSDs, you'll not notice the problem again, esp. if
| these are backed by RAID (even md counts).
| justsomehnguy wrote:
| What do you prefer:
|
| ( ) a 1% chance the system would crawl to a halt but
| would work
|
| ( ) a 1% change the kernel would die and nothing would
| work
| commandersaki wrote:
| _This is a wrong belief_
|
| This is not about belief, but lived experience. Setting up
| swap to me is a choice between a unresponsive system (with
| swap) or a responsive system with a few oom kills or downed
| system.
| bayindirh wrote:
| > This is not about belief, but lived experience.
|
| I mean, I manage some servers, and this is my experience.
|
| > Setting up swap to me is a choice between a
| unresponsive system (with swap) or a responsive system
| with a few oom kills or downed system.
|
| Sorry, but are you sure that you budgeted your system
| requirements correctly? A Linux system shall neither fill
| SWAP nor trigger OOM regularly.
| adastra22 wrote:
| What pressure? If your ram is underutilized, what pressure
| are you talking about?
|
| If the slowest drive on the machine is the SSD, how does
| caching to swap help?
| bayindirh wrote:
| A long running Linux system uses 100% of its RAM. Every
| byte unused for applications will be used as a disk
| cache, given you read more data than your total RAM
| amount.
|
| This cache is evictable, but it'll be there eventually.
|
| Linux used to don't touch unused pages in the RAM in the
| older days if your RAM was not under pressure, but now it
| swaps out pages unused for a long time. This allows more
| cache space in RAM.
|
| > how does caching to swap help?
|
| I think I failed to convey what I tried to say. Let me
| retry:
|
| Kernel doesn't _cache_ to SSD. It swaps out unused (not
| accessed) but unevictable pages to SWAP, assuming that
| these pages will stay stale for a very long time,
| allowing more RAM to be used as cache.
|
| When I look to my desktop system, in 12 days, Kernel
| moved 2592MB of my RAM to SWAP despite having ~20GB of
| free space. ~15GB of this free space is used as disk
| cache.
|
| So, to have 2.5GB more disk cache, Kernel moved 2592 MB
| of non-accessed pages to SWAP.
| wallstop wrote:
| Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-79-generic
| x86_64)
|
| * Documentation: https://help.ubuntu.com * Management:
| https://landscape.canonical.com * Support:
| https://ubuntu.com/pro
|
| System information as of Tue Oct 21 10:53:44 PM UTC 2025
| System load: 0.0 Temperature:
| 40.0 C Usage of /: 9.1% of 97.87GB Processes:
| 303 Memory usage: 59% Users logged
| in: 0 Swap usage: 0% IPv4
| address for eno1: 192.168.1.20
|
| Expanded Security Maintenance for Applications is not
| enabled.
|
| 29 updates can be applied immediately. To see these
| additional updates run: apt list --upgradable
|
| Enable ESM Apps to receive additional future security
| updates. See https://ubuntu.com/esm or run: sudo pro
| status
|
| ** System restart required ** Last login: Sun Sep 28
| 02:05:15 2025 from 192.168.1.23
|
| wallstop@fridge:~$ swapon --show NAME TYPE SIZE USED PRIO
| /swap.img file 4G 0B -2
| adgjlsfhk1 wrote:
| The OS uses almost all the ram in your system (it just
| doesn't tell you because then users complain that their
| OS is too ram heavy). The primary thing it uses it for is
| caching as much of your storage system as possible. (e.g.
| all of the filesystem metadata and most of the files
| anyone on the system has touched recently). As such, if
| you have RAM that hasn't been touched recently, the OS
| can page it out and make the rest of the system faster.
| vasco wrote:
| In EC2 using any kind of swapping is just wrong, the
| comment you replied to already made all the points that can
| be made though.
| bayindirh wrote:
| From my understanding, the comment I'm replying to uses
| EC2 example to portray that swapping is wrong in _any and
| all circumstances_ , and I just replied with my
| experience with my system administrator hat.
|
| I'm not an AWS guy. I can see and touch the servers I
| manage, and in my experience, SWAP works, and works well.
| 01HNNWZ0MV43FF wrote:
| It's not just 3 seconds for a button click, every time I've
| run out of RAM on a Linux system, everything locks up and it
| thrashes. It feels like 100x slowdown. I've had better
| experiences when my CPU was underclocked to 20% speed. I
| enable swap and install earlyoom. Let processes die, as long
| as I can move the mouse and operate a terminal.
| zozbot234 wrote:
| > It feels like 100x slowdown.
|
| Yup, this is a thing. It happens because file-backed
| program text and read-only data eventually get evicted from
| RAM (to make room for process memory) so every access to
| code and/or data beyond the current 4K page can potentially
| involve a swap-in from disk. It would be nice if we had
| ways of setting up the system so that pages of code or data
| that are truly critical for real-time responsiveness
| (including parts of the UI) could not get evicted from RAM
| at all (except perhaps to make room for the OOM reaper
| itself to do its job) - but this is quite hard to do in
| practice.
| KaiserPro wrote:
| Yeahna, thats just memory exhaustion.
|
| Swap helps you use ram more efficiently, as you put the hot
| stuff in swap and let the rest fester on disk.
|
| Sure if you overwhelm it, then you're gonna have a bad day,
| but thats the same without swap.
|
| Seriously, swap is good, don't believe the noise.
| gchamonlive wrote:
| It's good, and Aws shouldn't disable it by default, but it
| won't save the system from OOM.
| adastra22 wrote:
| I don't understand. If you provision the system with enough
| RAM, then you can for every page in RAM, hot or not.
| zymhan wrote:
| Where on earth did you get this misconception?
| commandersaki wrote:
| Lived experience? With swap system stays up but is
| unresponsive, without it is either responsive due to oom
| kill or completely down.
| GuinansEyebrows wrote:
| in either case, what do you do? if you can't reach a box
| and it's otherwise safe to do so, you just reboot it. so
| is it just a matter of which situation occurs more often?
| shrubble wrote:
| It's always a good idea to have a tiny amount of swap just in
| case. Like 1GB.
| awesome_dude wrote:
| How do you get swap on a VPS?
| 999900000999 wrote:
| Two question.
|
| What's in it for Disco ?
|
| What's the pricing ?
|
| How many work hours per month does keeping this thing stable
| take.
|
| If it takes over 15 Heroku is cheaper.
|
| Hosting with bare metal is still expensive, you pay in other
| ways.
| jf93ap29sh wrote:
| Cool to hear on the savings. But now the team has to maintain two
| different deployment models, so you have account for the ongoing
| cost that your team now has to own and maintain two different
| processes of deployment (prod & staging).
|
| The key element here is the need to continuously exercise both
| processes (Heroku + your staging server), to work out both
| processes & maintain familiarity on both.
|
| Depending on the amount of staff involved in the above, it might
| eclipse the compute savings, but only OP knows those details. I'm
| sure they are a smart bunch.
| Havoc wrote:
| Good improvement, but 50x overpayment until a rethink is also
| pretty wild.
| gregsadetsky wrote:
| From having talked to many folks, migrations are
| psychologically very, very, very very hard.
|
| At least, the "fear" factor (will the new system work? what
| bugs will it introduce? how much time will I spend, etc.)
| pushes a lot of folks to accept a very big price differential
| aka known knowns versus unknowns...
|
| It's understandable really. It's just that once you've
| migrated, you almost definitely never want to go back :-)
| pentacent_hq wrote:
| Cool project!
|
| From looking at your docs, it appears like using and connecting
| GitHub is a necessary prerequisite for using Disco. Is that
| correct? Can disco also deploy an existing Docker image in a
| registry of my choosing without a build step? (Something like
| this with Kamal: `kamal --skip-push --version latest`)
| gregsadetsky wrote:
| Correct, GitHub is necessary at this point to deploy code.
|
| However, yes, you can ask Disco to fetch an existing Docker
| image (we use that to self-host RabbitMQ). An example of
| deploying Meilisearch's image is here [0] with the tutorial
| here [1].
|
| Do you typically build your Docker images and push them to a
| registry? Curious to learn more about your deployment process.
|
| [0] https://github.com/letsdiscodev/sample-
| meilisearch/blob/main...
|
| [1] https://disco.cloud/docs/deployment-guides/meilisearch
| jdprgm wrote:
| Just saw Nate Berkopec who does a lot of rails performance stuff
| posting about the same idea yesterday saying Heroku is 25-50x
| price for performance which is so insane. They clearly have zero
| interest in competing on price.
|
| It's a shame they don't just license all their software stack at
| a reasonable price with a similar model like Sidekiq and let you
| sort out actually decent hardware. It's insane to consider Heroku
| if anything has gotten more expensive and worse compared to a
| decade ago yet in comparison similar priced server hardware has
| gotten WAY better of a decade. $50 for a dyno with 1 GB of ram in
| 2025 is robbery. It's even worse considering running a standard
| rails app hasn't changed dramatically from a resources
| perspective and if anything has become more efficient. It's
| comical to consider how many developers are shipping apps on
| Heroku for hundreds of dollars a month on machines with worse
| performance/resources than the macbook they are developing it on.
|
| It's the standard playback that damn near everything in society
| is going for though just jacking prices and targeting the
| wealthiest least price sensitive percentiles instead of making
| good products at fair prices for the masses.
| czhu12 wrote:
| > It's a shame they don't just license all their software stack
| at a reasonable price with a similar model like Sidekiq and let
| you sort out actually decent hardware
|
| We built and open sourced https://canine.sh for exactly that
| reason. There's no reason PaaS providers should be charging
| such a giant markup over already marked up cloud providers.
| nicoburns wrote:
| This looks decent for what it is. I feel like there are
| umpteen solutions for easy self-hosted compute (and tbh even
| a plain Linux VM isn't too bad to manage). The main reason to
| use a PAAS provider is a managed database with built-in
| backups.
| gregsadetsky wrote:
| Fully agreed - our recommendation is not /not/ run your
| prod Postgres db yourself, but use one of the many great
| dedicated options out there - Crunchy Data, Neon, Supabase,
| or AWS RDS..!
| bcrosby95 wrote:
| It really depends upon how much data you have. If its
| enough to just dump then go crazy. If it isn't its a bit
| more trouble.
|
| Regardless, you're going to have a much easier time
| developing your app if your datastore access latency is
| submillisecond rather than tens of milliseconds.
|
| So that extra trouble might be worth it...
| odie5533 wrote:
| Does it run Sentry and I can send logs, metrics, and traces
| to it, and the queries are fast?
| teiferer wrote:
| It's insane how much my local shop charges for an oil change, I
| can do it much cheaper myself!
|
| It's insane how much a restaurant charges for a decent steak, I
| can do it much cheaper myself!
|
| ...!
| jdprgm wrote:
| I know you mean this sarcastically but I actually 100% agree
| with this particular on the steak point. Especially with beef
| prices at all time record highs and restaurant inflation
| being out of control post pandemic. It takes so much of the
| enjoyment out of things for me if I feel i'm being ripped off
| left and right.
| grebc wrote:
| Where's the beef inflation? Local butcher has prime rib
| fillet $30 AUD/KG cut to your liking.
| rascul wrote:
| One also doesn't get shamed by the steak snobs if you have
| different steak preferences.
| andrewstuart2 wrote:
| This argument doesn't work with such commoditized software.
| It's more like comparing an oil change for $100 plus an hour
| of research and a short drive against a convenient oil change
| right next door for $2,500.
| teiferer wrote:
| Nobody is forced to go to the expensive one. If they are
| still in business then enough people apparently consider it
| a reasonable deal. You might not, but others do. Whether
| I'm being downvoted or not.
| xmprt wrote:
| Not the best comment but I agree with the sentiment. I fear
| far too often, people complain about price when there are
| competitors/other cheaper options that could be used with a
| little more effort. If people cared so much then they should
| just use the alternative.
|
| No one gets hurt if someone else chooses to waste their money
| on Heroku so why are people complaining? Of course it applies
| in cases where there aren't a lot of competitors but there
| are literally hundreds of different of different options for
| deploying applications and at least a dozen of them are just
| as reliable and cheaper than Heroku.
| strken wrote:
| The problem with Heroku's pricing is that it's set high
| enough that I no longer use it and neither does anyone else
| I know. I suspect they either pivoted to a different target
| market than me, which would be inconvenient but I'd be okay
| with it, or killed off their own growth potential by trying
| to extract revenue, which I would find sad.
| g8oz wrote:
| The price value proposition here seems similar to that of a
| stadium hot dog.
| raincole wrote:
| It's just trendy to bash cloud and praise on-premises in
| 2025. In a few years that will turn around. Then in another
| few years it will turn around again.
| artifaxx wrote:
| Indeed, there are levels to the asymmetry though. Oil change
| might be ~5x cheaper vs the 20-50x claimed for Heroku...
| layoric wrote:
| > $50 for a dyno with 1 GB of ram in 2025 is robbery
|
| AWS isn't much better honestly.. $50/month gets you an
| m7a.medium which is 1 vCPU (not core) and 4GB of RAM. Yes
| that's more memory but any wonder why AWS is making money hand-
| over-fist..
| varispeed wrote:
| Why people discover it only today? I remember making comments
| about it years ago.
|
| I even shown one customer that their elaborate cluster costing
| PS10k a month could run on a PS10 vps faster and with less
| headache (they set it up for "big data" thinking 50GB is massive.
| There was no expectation of the database growing substantially
| beyond that).
|
| Their response? Investors said it must run on the cloud, because
| they don't want to lose their money if homegrown setup goes down.
|
| So there is that.
| cpursley wrote:
| Any Elixir/Gleam/Erlang (distributed) support?
| gregsadetsky wrote:
| I don't know! I do see a Docker image for Elixir, so I'm pretty
| sure that would work. But the distributed aspect is harder to
| answer right now.
|
| How do you typically deploy this?
| cpursley wrote:
| Render (because it's on k8s) and Fly handle distributed
| erlang out of the box, so I don't have to think much about
| it. Heroku does not.
| codyb wrote:
| Amazing to see this article in 2025. Feel like it's 2015 all over
| again!
| merelysounds wrote:
| The article's title seems inaccurate - as far as I understood
| there never was a $3000/mo bill; there was a $500/(mo,instance)
| staging setup that has been rightly optimized to $55/mo before
| running six instances.
|
| > Critically, all staging environments would share a single "good
| enough" Postgres instance directly on the server, eliminating the
| need for expensive managed database add-ons that, on Heroku,
| often cost more than the dynos themselves.
|
| Heroku also has cheaper managed database add-ons, why not use
| something like that for staging? The move to self hosting might
| still make sense, my point is that perhaps the original staging
| costs of $500/mo could have been lower from the start.
| gregsadetsky wrote:
| I answered elsewhere with the list of dynos, but the short
| version is that between the list of services that each
| deployment required, and the size of the database, it truly
| (and unfortunately) did end up costing $500 per staging.
| cantalopes wrote:
| I don't mean to hate but i find it incredibly alarming that i'm
| lately seeing all the seemingly seniorly positioned people
| writing articles about how they just realized that you can
| actually just buy a vps, setup a deployment workflow and write a
| revealing blog about "drastically cutting costs".
|
| It's like juniors who did not recieve a proper training/education
| got hired into companies where someone told them to go serverless
| on some heroku or vercel, or use some incredibly expensive aws
| service because that's a "modern correct way" to do it, except
| now they were a developer for long enough to get a "senior" title
| in their job title now are in positions of actually modelling
| this architecture themselves
| ksajadi wrote:
| It is clear that Heroku is not interested in reducing their
| prices. But I don't think this is a Heroku problem. Vercel is
| also the same, which makes me think there is a fundamental issue
| with the PaaS business model that stops it from competing on
| price while the commoditised part their business (data centers)
| are always reducing their prices.
|
| The challenge I always face with homebrew PaaS solutions is that
| you always end up moving from managing your app to managing your
| PaaS.
|
| This might not be true right now but as complexity of your app
| grows it's almost always the eventual outcome.
| IshKebab wrote:
| On the other hand for $3k/month you can just hire someone to do
| it for you (part time at least, but I doubt it's remotely a
| full-time job).
| afro88 wrote:
| Doesn't staging need to be a (downsized) replica of prod, infra
| wise to give confidence that changes will be stable and working
| in prod?
|
| Genuine question.
| iamjs wrote:
| > Bridging the Gap: Why Not Just Docker Compose?
|
| The draw of a docker-compose-like interface for deployment is so
| alluring that I have spent the last year or so working on a tool
| called Defang that takes a compose file and deploys it to the
| cloud. We don't support Hetzner (yet), but we do support AWS,
| GCP, and DO. We provision networking, IAM, compute, database,
| secrets, etc in your cloud account, so you maintain full control,
| but you also get the ergonomics of compose.
|
| If you are on a PaaS and you want to reduce cost without losing
| ergonomics and scalability, it might be interesting.
| pier25 wrote:
| Can anyone comment on how Disco compares to Dokku?
| plehoux wrote:
| Congrats Greg & Antoine! disco.cloud is really needed, I hope you
| guys get the visibility you deserve and some momentum from the
| community!
| outside1234 wrote:
| It is absolutely nuts to me that this machine:
|
| AMD Ryzen(tm) 7 3700X CPU 8 cores / 16 threads @ 3.6 GHz
| Generation: Matisse (Zen2) RAM 64 GB DDR4 ECC
|
| Drives 4 x 22 TB HDD 2 x 1 TB SSD
|
| is only 104 euros a month on Hetzner.
|
| The STORAGE alone would cost $1624 a month in most clouds
| whalesalad wrote:
| There is still so much room for someone to take over where Heroku
| left off and eat their lunch. Railway is probably the closest
| spiritual successor who appears to be doing it right. It would be
| awesome to have a managed platform like this where I can drop-in
| my own AWS, GCP, etc creds and still have control over the
| underlying infra, tho.
|
| Will take this for a spin, it looks like it does what I am
| describing.
| morshu9001 wrote:
| I like Heroku for my needs but have noticed oddities in the
| pricing that can make a small app cost much more than a
| differently arranged large app.
| hu3 wrote:
| Very cool project. Is there an overview of the architecture?
| Perhaps a diagram or some drawing?
|
| I mean something like a list of moving parts so I can understand
| how it works. Perhaps something like this:
|
| https://caprover.com/#:~:text=CapRover%20Architecture%20at%2...
___________________________________________________________________
(page generated 2025-10-21 23:00 UTC)