Skip to content


This document describes how to get started using Blunix for hosting servers and cloud instances. It is addressed to Blunix SLA customers.

Blunix GmbH requires the following in order to host Blunix Stack for you:

Technical Contact Person

Blunix GmbH requires at least one technically versed contact person on the customers side:

Compontent Used for
Element Chat account Communication with Blunix GmbH consultant
Signal Chat account Backup communication with Blunix GmbH consultant
E-Mail Address Commonly as account username, for monitoring notifications and similar


The following third party provider accounts are required to host Blunix Stack:

Compontent Used for
Cloud provider admin credentials creating and managing servers
DNS provider admin credentials managing DNS records
SMTP account sending monitoring alerts, gitlab notifications and others

Cloud Provider

Infrastructure hosted with Blunix Stack can be installed and managed on most any cloud or physical hardware provider. It can also be hosted on several different providers at the same time. Physical hardware, like Hetzner dedicated root servers or your own servers in your own on-site datacenter are also supported.

If you choose physical servers, Blunix Stack can setup Proxmox to provide cloud functionality, or manage a Debian installation on the physical server directly.

The following technical requirements have to be met by the hosting provider:

Instance Ressources

The minimum requirements for all servers are:

  • Debian Linux stable
  • 60 GB Disk for the root partition
  • 2 GB RAM
  • 2 CPU Cores
  • 1 static public IP (IPv4 or IPv6)


  • Servers / Cloud instances can be provisioned with Debian stable automatically (no manual install required)
  • Servers can allocate public IPs that are shutdown persistent
  • RAM, CPU and Disk can be scaled up during runtime (down with reboot, not required for physical hardware)
  • Servers can be (easily) accessed through a rescue system in case the original installation is not responding
  • The cloud provider is not AWS or Google Cloud


  • The cloud provider can "failover" public IPs between instances using an API call
  • The cloud provider provides an API for monitoring resource outages and problems with instances
  • The cloud provider is Hetzner or SysEleven OpenStack
  • The cloud provider is not 1und1 IONOS