Hardware & resources
The server (host) machine can be:
a physical computer (dedicated server, repurposed desktop/laptop, small factor board…)
a virtual machine (VM)
a VPS from a hosting provider
Resource usage will vary depending on installed components (read each role’s documentation), the number of concurrent users, and how much user data you need to store. Example minimal configuration for a personal/small team server with 2-10 users:
Computer with x86/64 compatible CPU 1024-2048+ MB RAM 10+ GB storage for system and applications files 1-∞ GB storage for user data
If hosting on a physical server, prefer low power consumption hardware. Setup the BIOS to reboot after a power loss. If availability is important, setup hardware-level redundancy/failover mechanisms such as RAID, multiple network links, an UPS, and/or multiple power supplies.
The server must have a valid IPv4 address and gateway set during operating system installation.
The server must have a valid DNS resolver set during installation. You can either use:
The server must have Internet access during deployment and upgrades.
Prefer fast and reliable network links.
If the network interface is in a private network behind a router, setup port forwarding (NAT) on the router if you need to access your services from other networks/Internet. Depending on which services are installed on the server, forward the following ports to your server’s private IP address (if corresponding services are installed):
SSH server: TCP 22 Netdata monitoring system: TCP 19999 Web server: TCP 80/443 BitTorrent incoming connections: TCP/UDP 52943 Mumble VoIP server: TCP/UDP 64738 Graylog TCP input: TCP 5140 Dovecot IMAP server: TCP 993
The controller must be able to resolve the server’s name from the inventory, using either:
CNAMEDNS records to the public IP address of your server, from:
hosts file entries
ansible_hostvariable in the host’s configuration file (e.g.
Prefer using Fully Qualified Domain Names. Accessing the host directly by IP address is discouraged, use DNS records.
Public DNS records are required to obtain Let’s Encrypt SSL/TLS (HTTPS) certificates - private DNS records will not work (you may still use self-signed certificates).
Separate domain/subdomain names are required to allow clients to access web applications. For example:
***.CHANGEME.org # host name in the inventory/playbook www.CHANGEME.org # homepage cloud.CHANGEME.org # nextcloud git.CHANGEME.org # gitea links.CHANGEME.org # shaarli rss.CHANGEME.org # tt-rss torrent.CHANGEME.org # transmission mumble.CHANGEME.org # mumble server ldap.CHANGEME.org # openldap server/LDAP account manager ssp.CHANGEME.org # LDAP self-service password chat.CHANGEME.org # rocketchat media.CHANGEME.org # jellyfin logs.CHANGEME.org # graylog tty.CHANGEME.org # gotty rss-bridge.CHANGEME.org # rss_bridge imap.CHANGEME.org # mail_dovecot
External SMTP server
For your applications/services/monitoring tools to be able to send e-mail (notifications, confirmations, reports…), a valid account on an external e-mail (SMTP) server must be configured (see
*mailer* configuration variables). By default all outgoing e-mail functionality is disabled and you will not receive any e-mail from your servers.
You can use your own SMTP server or a commercial e-mail service such as Mailjet (requires public DNS A and TXT DNS records for the host), or a Gmail (requires enabling 2FA and less-secure app access) or other   e-mail account.
Base Operating System
You should now prepare the controller.