Green/carbon neutral NixOS hosting

I’m looking for VPS hosters that

  • Accept NixOS ISOs or even have a NixOps interface.
  • Run 100% on renewable energy.

Additional perks:

  • Elastic storage space, or plans for higher storage (>50 GB) with low other resources
  • Within 30€/month
  • Europe

I’ve found very little in that regard.

  • AWS has elastic everything and claims to have some carbon-neutral regions (e.g. Frankfurt), but as most things AWS this is hard to check for me.
  • There is greengeeks, but they are expensive (if you go for a lot of storage).
  • There is Solar Powered VPS - Green Cloud VPS Hosting | AISO.Net, but it’s still surprisingly expensive as compared to, say, Hetzner Cloud.

Does anyone have other recommendations? Or can someone assure that AISO is as cheap as it gets?


By the way, Hetzner also uses renewable energy (Hetzner - Wikipedia) and can run NixOS. I’m running a small VPS with NixOS there.


Update: Greengeeks doesn’t offer custom ISOs.

Wow! I wonder why they don’t make more publicity from that, and how they can still afford to be so cheap in comparison to Greengeeks and others.

I think it’s because their primary focus is on hosting, not on energy ;).
But you can find the information on their website:

1 Like

If you speak German, this is looking good:
Good dedicated servers running on renewable energy for surprisingly little money.

Accept NixOS ISOs or even have a NixOps interface.

why is that a requirement?

Just use on any hosted OS. In my experiments it takes < 5min to infect machine and reboot into NixOS.

I’ve used this for Hetzner and our local cloud hosting (and people say it works for Digital Ocean and OVH)

I have no experience with nixos-infect. Some people say it doesn’t work well. If it does, then it’s maybe no requirement.

Accept NixOS ISOs or even have a NixOps interface

Just FYI, nixops does not connect securely to several non-cloud-native backends like hetzner and physical machines, allowing potential hackers to intercept eg. deployment.keys sent to a machine.

See StrictHostKeyChecking=no is insecure · Issue #696 · NixOS/nixops · GitHub for details.

Note that this has to do with StrictHostKeyChecking, which does not imply implies (see below) that host keys aren’t checked at all (eg. an attacker MITMing your already deployed host won’t succed). The main problem for the Hetzner target is that we can’t do a lot about it, because the rescue system (which is what is used for initial deployment) already comes with a newly generated host key every time and if you’re being MITMed during initial deployment, you’re already doomed at that point. That said, there is however a race in between the robot and the initial deployment, so if you’re rebooting from the rescue system into the newly deployed system the host key is added initially after the reboot. As mentioned in comments of that issue, this gap could be closed by generating the host key via nixops and sending it to the host during the first deployment.

Doing that however, still doesn’t solve the issue in the first place and we’d need a way to securely verify whether we’re in the real rescue system rather than a MITM host, so I’m going to ask Hetzner whether they could implement something like this (preferrably by getting the host key via Robot API).

Another attack vector is when you export the deployment without known_hosts and you get MITMed during the next connection after importing somewhere else.

So in summary: The situation (at least for the Hetzner backend) is not worse than it is even without NixOps (except maybe the export/import point mentioned before). If something like this is a concern to you, you probably shouldn’t use a hoster that regenerates SSH host keys in rescue, except of course if you have a way to verify that it’s indeed the real target system.

Nevertheless, that issue is on my todo list already, but it needs a lot of testing (and for the Hetzner backend a change of their API) so it might take a while :unamused:

Edit: Actually, I was wrong on StrictHostKeyChecking… it really just adds the host key even on mismatch. While you do get big fat warning, this still will connect to the target anyway. OpenSSH 7.5 has the accept-new option, which I added in #1023. With this pull request merged, what I wrote above is the case (even with the goofs, this is not a full fix).

Edit 2: Hetzner does seem to have a way to get the host key of the rescue system: Robot Webservice


netcup runs on green energy, is available in english and in german, and allows you to upload your own iso file. I regularily build my own isos preloaded with my ssh keys etc.

It’s listed in the NixOS wiki’s NixOS friendly hosters page, together with more detailed installation instructions.


Thanks, that’s helpful! How do you create an ISO?

You’re welcome: Creating a NixOS live CD - NixOS Wiki :nix_parrot:

I use Hetzner too. They give you a choice of hydro power or wind power. And I like their control panel interface and backup options, and they’re very cheap.