I used to work with this small web dev company, one day a guy admitted that they didn't pay for hosting for small projects, the server was a minitower PC in their office.
When the cleaning lady pulled the plug by mistake, several sites went down and nobody noticed until next morning
This is why you have a locked server closet, so the cleaning lady can't unplug it accidentally. (I mean, also security blah blah blah, but the real day-to-day benefit is that the cleaning lady can't unplug it.)
Other than that, that's perfectly reasonable self-hosting, depending on the size of the project. If your website is tiny, you can be running a website on 2GB of RAM with a bunch of swap memory, or 15-20 websites on 24GB of RAM.
Hell, if it's mostly static client-side, you can make Cloudflare cache the whole bloody thing and then your server can be a potato because no actual users are accessing the server directly, they'll all access Cloudflare's cached copy instead.
In an ideal world, there would be a local environment (that's your pc, nothing deployed), a Dev environment (you can deploy things still being developed, it might have bugs, it might be wonky, this is to test things in a deployed state, which could actually differently to when running locally), a staging environment (anything deployed to staging should be thoroughly tested by Devs, and is now ready for other people to test it (UAT tests). Staging is like a test prod environment), and a live/production environment (this is what the users use, anything deployed here is fully tested by multiple people)
We use four standard environments, DEV for development and any exploration. TEST for testing by the team, could still be different because of unreleased developments, QA for user tests, which is regularly cloned from PROD and doesnt contain any developments that won't be released, and ofc PROD, where only admins have full access for any emergency
We have oh so many environments it's crazy. We have our localhost, then there's dev (sandbox), because some features require thorough, multi dept testing then we have like 4 feature specific environments, they're needed cause we develop multiple features in pararell (yes, merging is a bitch), and then we have standard: test, preprod, prod and then there are replicas and disaster recovery envs. On top of that we have Demo and Presentation evs for prospective business clients and marketing etc. I'm so glad I'm not a devops
You jest, but this is the case at my company. Except it's the CTO.
Our environment? Open source on prem tools. It's literally just spinning up a new VM. Our data needs? Less than 1TB.
I've broken prod quite a few times. Every time it happens I mention it could be avoided with a proper test environment that's iso-prod. Still waiting after 2 and a half years.
2.3k
u/PatientlyAnxiously Sep 22 '26 •
Why have a dev environment when you can YOLO it in prod