They are cool, man they've grown. I used that when there were ~20 VM's on there. Its a great project but think its only physically in Amsterdam which is why I ended up moving back to vultr, as they have many more options.
Man I always look at this project with nothing by awe. I'd love to start something like this... if you're in central Switzerland and would like to copy their model, hit me up.
openbsd.amsterdam is notable because they use the openbsd native vmm as the vm host. It is obsd all the way down over there.
It is a small and no frills service but the sys-admin, who runs the project, is very helpful and attentive. That is to say probably much better and human customer service than the big players. There are definite downsides, but if a project fits, highly recommended.
Great service for small personal blog or a testbed. OpenBSD has httpd + acme client for SSL termination & automated rotation so the base system has just enough to host a low traffic website. For anything that requires uptime one will have to buy multiple VMs and handle the uptime story themselves, since they go down regularly for maintenance.
The fact that they donate back to OpenBSD is great though. I own a VM there for testing stuff.
I've always gone with Vultr (vultr.com) for BSD VMs, its properly supported by them and while I've never hard verified this, they seem like a nice smaller player. Like they have offered Open/Free BSD VM's for > 10 years, kind of nice.
The admins have access to your data and unless things have changed, that isn't monitored. They also bend to NSLs like any other provider. What they charge vs what things cost hurts.
And to clarify, this means encrypt it before it gets to the VPS. Just having full-disk encryption is not enough because cloud providers can dump RAM. There are tools that easily extract encryption keys from RAM.
So, really, you need to trust the cloud provider unless everything is encrypted on computers you own.
> And to clarify, this means encrypt it before it gets to the VPS. Just having full-disk encryption is not enough because cloud providers can dump RAM. There are tools that easily extract encryption keys from RAM.
True, but at the very least, you won't have to worry about discarded SSDs having your data in plaintext.
They were very helpful when one of the AMD firmware patches in 7.3 caused my VPS to not boot. They even offered to apply a manual fix until patch -015 was available which fixed it.
I have a couple of FreeBSD VMs on Vultr. For quite some time sshd regularly dies on one of them and I am not sure why.
A couple of theories I’ve had is that maybe
a) my VM was compromised and there is a persistent rootkit installed that kills sshd, or
b) file corruption after previous unclean shutdown has left some file needed by sshd corrupted and it leads to this behaviour, or
c) maybe it’s running out of memory sometimes
Each time I want to ssh into the machine I usually have to first connect with the VNC from the vultr dashboard to start sshd up again.
It’s running the latest FreeBSD, as every now and then I log in and do an upgrade on it some time after a new version has been released.
A persistent rootkit may have been installed if it was compromised between when some vulnerability became known and when I later upgraded next time.
If a file was corrupted in an unclean shutdown in the past maybe it’s a file that has not been changed between FreeBSD versions so even though upgrades replace some files maybe it’s the same corrupted file all along.
Ideally I’d just reinstall the machine, but that’s always more of a hassle than it should be so I continue running the VM in this broken state where sshd keeps dying every now and then.
Well, you can at least run "freebsd-update IDS" on this system to verify the base system, "pkg check -s -a" would check the integrity of files installed via pkg also.
While I’m at it I also took a quick look now at output of `top` and it’s sitting at 27 MB free RAM lol. So from that, out of memory is very likely the reason I keep having sshd die on me.
After rebooting the VM now, sshd died even when there was hundreds of megabytes free RAM available. So it seems I spoke too soon when I said it seemed to be for that reason.
Previously I haven't seen much detailed reason for why it dies in system messages. But this time it said something very specific:
> sshd[2036]: fatal: pack_hostkeys: serialize hostkey private: string is too large
Which kind of sounds like one of the sshd hostkey files might be corrupt? And maybe it only triggers after a while becuase it happens when scanners try to connect to it and during ssh negotiation sshd ends up selecting a different hostkey type than the one it uses when I connect to the machine myself?
I'm going to regenerate all of the three hostkey files on the server, and after that also disable the two that I can do without anyway.
Sounds like a you problem I've had multiple FreeBSD systems on vultr for over a decade and never had sshd issues. Of course I also use an alternate port and active fail2ban to block those who insist on any brute force for any protocol. 128K active blocks currently.
I remember when Vultr was new and had a single rack with a handful of boxes. They had low prices but you often had to wait for them to build a new box. Their whole schtick at the time was, "we are building this for people who know what they are doing, don't bother us for support, we don't have any."
But they are not that small anymore. They are now VC funded, operate in 33 datacenters worldwide and are currently spending $1 billion to build an AI datacenter in Ohio.
I've been considering https://openbsd.amsterdam/ as it seems like a nice way to donate to the project as well. For now I am using a lowest tier Hetzner instance. More RAM but less disk space (which is pretty inconvenient for OpenBSDs automatic partitioning IMO).
OBSD Amsterdam is pretty cool. I am currently running an instance on it. One feature that could also be considered a bug is that the VPSes run on the native OpenBSD virtualization scheme. My instance has suffered a few crashes over the years. It's been solid more recently. I suspect that OBSD Amsterdam and users have contributed to improvements to the native virtualization.
So you control your instance by sshing into a BSD account on the server. You configure your reverse DNS the same way. It's OpenBSD all the way down. So, as mentioned, pretty cool. Possibly not for the OBSD user who prefers some sort of web based configuration for their VPS.
It comes with access to a server you can copy your backups to. You of course do that from your instance using ssh.
Does DigitalOcean still only propose up to 4 basic cpu as droplet maximum ?.
All their compute capacities disappeared overnight 2025/2026 without any reason.
If you can, it really makes sense to look for low cost dedicated servers. For $35/month I get a whole machine with dual L5520 and 24 GB of ram. I used to have a little nicer server for a little less, but that provider had to close because their costs for electricity and space went up too fast. Yes, the L5520 is ancient, but my server needs are tiny and it's fun to have a whole machine.
Look on webhostingtalk or lowendbox or lowendtalk.
I currently use hetzner and DO, but a while back when I was trying to find cheaper alternatives, and hetzner pretty good for its price to performance ratio. Smaller vps providers were crazy oversubscribed that would get pretty inconsistent performance.
None of the dedicated machines I found were cheaper, so I'm surprised someone is offering that for $35/month.
You can even go completely free with Cloudflare tunnel with your own office/home hardware. I have a simple web running on my old Raspberry Pi 3 + nginx + golang web app. Also with ssh access to the Pi.
Yes, the cloudflare SSH tunneling works well -- though I think the fact that SSL is provisioned means it'll show up in the cert transparency log, possibly attracting unwanted attention to probe my home systems.
I ended up turning that off and switching to Tailscale. Tailscale is set to advertise my home IP range (I chose one that's not 192.168 based which avoids problems with range conflicts). So I can just connect to Tailscale and connect to 10.X.Y.Z as though I'm home. If I want memorable hostnames I can point DNS records to those private IPs.
You don't even need your own hardware. You can serve your site using the free CF Workers plan. Of course, that's a different goal than running bsd in an aggressively tiny cloud instance.
I've thought about this as well but I was not too comfortable with it.
As I understand it it is a reverse tunnel from your internal network to cloudflare? If your device is compromised it may lead to an attacker using that tunnel to access your internal network through the host device?
They're also too stupid to understand that they've been dropping UDP datagrams with src port == dst port and < 1024. This obviously breaks IPsec IKE. I showed them dummy traffic captured with netcat and tcpdump, but they refused to admit they caused the problem. They repeatedly claimed to see nothing dropped between the pcap files, that I was doing it to myself with a firewall that wasn't even enabled, or that this is just how a network is supposed to work.
I migrated a client off for the same reason. The “app platform” ran behind Cloudflare, but they run the Cloudflare, so I couldn’t put it behind my own Cloudflare, nor could I configure it and solve the problem. Moved the entire thing to Hetzner, fast. What a week.
A warning about openbsdhandbook[.]com - this website has completely incorrect information for some things. Like hallucinated, even though I think it was created before LLMs.
For BSD (especially OpenBSD) you can pretty much just use the man pages and the online FAQ. They are really good.
If you want a book, Absolute OpenBSD is good though a bit out of date now. A lot of it would still be applicable though, if backed up by the current man pages.
Dang, I didn't know that. I thought it was decent enough to get people exposed to doas(1), pkg_add(1), syspatch(8), etc... from which they could then read the man pages.
Thanks for pointing this out and I appreciate the other recommendations in this thread. Massive +1 for @jcs. That dude is awesome and puts out great stuff.
That pricing is awful. $4/month for 512MB VPS...eeek.
You'll find much better pricing at RackNerd, DediRock, InterServer, BuyVM, etc. Small indy hosting companies are the way to go. 2GB for $5/month or so is the typical price point.
Any host that offers KVM and allows you to upload your own ISO can run OpenBSD (or FreeBSD, NetBSD, whatever you want).
Check out LowEndTalk or LowEndBox for deals. There are other sites but that's where I shop.
Sure, if you need an API, or if you want to host in one of the less common locations, or if you absolutely must have five nines, then DO or Vultr or Linode or Amazon LightSail can be a good fit. But if you just need a VPS with a control panel in a typical hosting location (Amsterdam, LA, New York, Chicago, Singapore, etc.) then I don't see the point of paying more at one of the big hosts.
OVH VPSs are particularly nice for RAM. Something in the 4-5 USD range can give you 4GB. The issue is patience with availability, sometimes it takes a while to get one in the location you want.
same impression. When you want to have memory hangry MariaDB to run fast, RAM is most important, and OVH prices are insanely cheap comparing to basically everyone else.
BuyVM is scammy. They offer a "$1" Plan but all locations are out of stock. Tnen they say it's available on cloudvm where the same package starts at $3
The claim that BuyVM is scammy contradicts my experience. I have had excellent customer service from them. Yes, like (say) airline tickets, the demand for their lowest-priced offerings exceeds the supply available at that price point, and if you're not willing to wait, you will pay more. But new supply seems to come online about twice a month when billing cycles expire, and there is a Discord channel ("BuyVMStock") that can alert you when this happens. Me, I'm hanging on to my underutilized server there just because it's so cheap to keep at the ready, and I suppose this is why they have so little availability. But if they were actually scammy there would be much more churn.
Tbf, they could have become scammy. The previous owner , Francesco , recently (less than a year ago?) sold BuyVM because he wanted to focus on a new endeavor.
That being said, BuyVM stock was always low. You had to register on some website were you were told when what you wanted became available.
Too many of these low end rsellers are unreliable, creep into your VM and unprofesionally fight with customers in the forums. They are children. Go with one that owns the hardware.
Yeah. Back in ~2011, when I was in high school, I used to sell these kinds of VMs as a host and advertised on LowEndBox. Literally as a minor. I don't really trust any small time host with my data.
Meanwhile I recently migrated a $5 DigitalOcean VM that's been running flawlessly for over 6 years. It was in dire need of an Ubuntu upgrade. I expect this one to keep going for just as long!
No idea why you're being downvoted. I've bought el cheapo LowEndTalk-style VPS specials on two or three occasions and have gotten what I paid for each time. They either sold a microscopic slice of some over-provisioned 15-year-old POS or outright lied to me about specs then argued until I did a chargeback to recover my money.
For app hosting I'd either 1) use cloudflared and a cheap Lenovo Tiny box to host from my house, 2) write something serverless that runs on Cloudflare Workers, or 3) use a real host that isn't 18 months old and run by hucksters in a race to the bottom.
Not necessarily. I've been using a couple of RackNerd VPSs for non-critical stuff for a few years now and they have been rock solid. Hetzner and Contabo are also reputable providers with competitive pricing.
I recently migrated from Digital Ocean to Scaleway. Digital Ocean was great but I had to make sure my stack was entirely in the EU in case the US decides to hit a kill switch for some mental negotiation tactic. Pricing and interface and performance are all similar.
I've had a 1GiB VPS for a while. I'm starting to think that I could have done with 512MB for the fairly simple jobs I have on it. As long as I get 1 whole CPU slice (no slowdowns) I'd be ok.
Always happy to see more people having fun with OpenBSD. Running my own set of OpenBSD boxes (although the public-facing ones are on Hetzner), so I read through the instructions and it aligns with my own experience (although I usually emphasise that most correct choices in the installer are just the default). However, this part: "Since this is going to be a bare-bones web server we can remove most of the sets.". This is not great advice. Reducing the number of sets even on a headless server can lead to issues with ports depending on libraries Xenocara provides that would then be missing (fonts, etc.). Likewise, when you upgrade the default is to install all sets unless you manually intervene, which could lead to a surprise bump in disk usage that you may not have accounted for. In general, reducing the number of sets should be considered "I am deviating from the defaults and I know what I am doing" territory and Theo keeps threatening to remove the option to select the sets in the installer when people complain and I am inclined to agree with him.
89 comments
[ 0.28 ms ] story [ 14.3 ms ] threadIt is a small and no frills service but the sys-admin, who runs the project, is very helpful and attentive. That is to say probably much better and human customer service than the big players. There are definite downsides, but if a project fits, highly recommended.
The fact that they donate back to OpenBSD is great though. I own a VM there for testing stuff.
rootbsd.net before that, but they don't seem to exist anymore.
And to clarify, this means encrypt it before it gets to the VPS. Just having full-disk encryption is not enough because cloud providers can dump RAM. There are tools that easily extract encryption keys from RAM.
So, really, you need to trust the cloud provider unless everything is encrypted on computers you own.
True, but at the very least, you won't have to worry about discarded SSDs having your data in plaintext.
A couple of theories I’ve had is that maybe
a) my VM was compromised and there is a persistent rootkit installed that kills sshd, or
b) file corruption after previous unclean shutdown has left some file needed by sshd corrupted and it leads to this behaviour, or
c) maybe it’s running out of memory sometimes
Each time I want to ssh into the machine I usually have to first connect with the VNC from the vultr dashboard to start sshd up again.
It’s running the latest FreeBSD, as every now and then I log in and do an upgrade on it some time after a new version has been released.
A persistent rootkit may have been installed if it was compromised between when some vulnerability became known and when I later upgraded next time.
If a file was corrupted in an unclean shutdown in the past maybe it’s a file that has not been changed between FreeBSD versions so even though upgrades replace some files maybe it’s the same corrupted file all along.
Ideally I’d just reinstall the machine, but that’s always more of a hassle than it should be so I continue running the VM in this broken state where sshd keeps dying every now and then.
It will only take a few min..
While I’m at it I also took a quick look now at output of `top` and it’s sitting at 27 MB free RAM lol. So from that, out of memory is very likely the reason I keep having sshd die on me.
Previously I haven't seen much detailed reason for why it dies in system messages. But this time it said something very specific:
> sshd[2036]: fatal: pack_hostkeys: serialize hostkey private: string is too large
Which kind of sounds like one of the sshd hostkey files might be corrupt? And maybe it only triggers after a while becuase it happens when scanners try to connect to it and during ssh negotiation sshd ends up selecting a different hostkey type than the one it uses when I connect to the machine myself?
I'm going to regenerate all of the three hostkey files on the server, and after that also disable the two that I can do without anyway.
But they are not that small anymore. They are now VC funded, operate in 33 datacenters worldwide and are currently spending $1 billion to build an AI datacenter in Ohio.
So you control your instance by sshing into a BSD account on the server. You configure your reverse DNS the same way. It's OpenBSD all the way down. So, as mentioned, pretty cool. Possibly not for the OBSD user who prefers some sort of web based configuration for their VPS.
It comes with access to a server you can copy your backups to. You of course do that from your instance using ssh.
Look on webhostingtalk or lowendbox or lowendtalk.
This is kind of exactly what I worry about with a dedicated box. That and hardware failure.
None of the dedicated machines I found were cheaper, so I'm surprised someone is offering that for $35/month.
I ended up turning that off and switching to Tailscale. Tailscale is set to advertise my home IP range (I chose one that's not 192.168 based which avoids problems with range conflicts). So I can just connect to Tailscale and connect to 10.X.Y.Z as though I'm home. If I want memorable hostnames I can point DNS records to those private IPs.
As I understand it it is a reverse tunnel from your internal network to cloudflare? If your device is compromised it may lead to an attacker using that tunnel to access your internal network through the host device?
We got IPv6 just so people can dot the exact same dumb shit with it that IPv4 forced us to do.
Switched to OVH immediately.
If you want a book, Absolute OpenBSD is good though a bit out of date now. A lot of it would still be applicable though, if backed up by the current man pages.
joshua stein's interest in getting OpenBSD running on anything he can provides useful insight too https://jcs.org/tagged/openbsd
Thanks for pointing this out and I appreciate the other recommendations in this thread. Massive +1 for @jcs. That dude is awesome and puts out great stuff.
You'll find much better pricing at RackNerd, DediRock, InterServer, BuyVM, etc. Small indy hosting companies are the way to go. 2GB for $5/month or so is the typical price point.
Any host that offers KVM and allows you to upload your own ISO can run OpenBSD (or FreeBSD, NetBSD, whatever you want).
Check out LowEndTalk or LowEndBox for deals. There are other sites but that's where I shop.
Sure, if you need an API, or if you want to host in one of the less common locations, or if you absolutely must have five nines, then DO or Vultr or Linode or Amazon LightSail can be a good fit. But if you just need a VPS with a control panel in a typical hosting location (Amsterdam, LA, New York, Chicago, Singapore, etc.) then I don't see the point of paying more at one of the big hosts.
* https://searxng.shreven.org/search?q=openbsd+ovhcloud
> Small indy hosting companies ... $5/month or so is the typical price point.
> I don't see the point of paying more at one of the big hosts.
I'm confused. People who are paying $4/mo at the big host should instead save money by paying $5/mo at a small host?
Check out BuyVM 3.50$ plan.
That being said, BuyVM stock was always low. You had to register on some website were you were told when what you wanted became available.
https://lowendtalk.com/discussion/186062/buyvm-always-out-of...
Meanwhile I recently migrated a $5 DigitalOcean VM that's been running flawlessly for over 6 years. It was in dire need of an Ubuntu upgrade. I expect this one to keep going for just as long!
For app hosting I'd either 1) use cloudflared and a cheap Lenovo Tiny box to host from my house, 2) write something serverless that runs on Cloudflare Workers, or 3) use a real host that isn't 18 months old and run by hucksters in a race to the bottom.
The wireguard tunnels haven’t gone down after years of no maintenance use.
https://urlhaus.abuse.ch/asn/14061 https://threatfox.abuse.ch/asn/14061
(However it's hosted only in Germany and does not have an API. Also, its SLA only guarantees 99% uptime.)
P/S: The website is running on a Raspberry Pi 3 in my house, hope HN won't hug it to dead
https://mikr.us/
But on a shared IPv4 as that what makes up much of the cost.