▄▄▄▄▄▄▄▄▄▄▄ ▄ ▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄
▐░░░░░░░░░░░▌▐░▌ ▐░▌▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌
▐░█▀▀▀▀▀▀▀█░▌▐░▌ ▐░▌ ▀▀▀▀█░█▀▀▀▀ ▐░█▀▀▀▀▀▀▀█░▌▐░█▀▀▀▀▀▀▀█░▌▐░█▀▀▀▀▀▀▀▀▀ ▀▀▀▀█░█▀▀▀▀
▐░▌ ▐░▌▐░▌ ▐░▌ ▐░▌ ▐░▌ ▐░▌▐░▌ ▐░▌▐░▌ ▐░▌
▐░▌ ▐░▌▐░▌ ▐░▌ ▐░▌ ▐░█▄▄▄▄▄▄▄█░▌▐░▌ ▐░▌▐░█▄▄▄▄▄▄▄▄▄ ▐░▌
▐░▌ ▐░▌▐░▌ ▐░▌ ▐░▌ ▐░░░░░░░░░░░▌▐░▌ ▐░▌▐░░░░░░░░░░░▌ ▐░▌
▐░▌ ▐░▌▐░▌ ▐░▌ ▐░▌ ▐░█▀▀▀▀▀▀▀▀▀ ▐░▌ ▐░▌ ▀▀▀▀▀▀▀▀▀█░▌ ▐░▌
▐░▌ ▐░▌▐░▌ ▐░▌ ▐░▌ ▐░▌ ▐░▌ ▐░▌ ▐░▌ ▐░▌
▐░█▄▄▄▄▄▄▄█░▌▐░█▄▄▄▄▄▄▄█░▌ ▐░▌ ▐░▌ ▐░█▄▄▄▄▄▄▄█░▌ ▄▄▄▄▄▄▄▄▄█░▌ ▐░▌
▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌ ▐░▌ ▐░▌ ▐░░░░░░░░░░░▌▐░░░░░░░░░░░▌ ▐░▌
▀▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀▀▀▀ ▀ ▀ ▀▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀▀▀▀ ▀
Stand-alone self-hosting infrastructure with security and a range of apps. Caddy for reverse proxy plus generally heavy use of Docker. Easy and straightforward to add more services as need.
Build yourself an outpost.
Repo URL: https://github.com/qu13t0ne/outpost
- Caddy v2 Reverse Proxy
- Including Caddy-Security for user authentication & MFA
- Note: Be sure to read the Important Reverse Proxy Setup Information in the Caddy readme file.
- Portainer - Lightweight Docker management web UI (mostly I just use for status monitoring)
- Budibase - Low-code platform
- CyberChef - Cyber Swiss Army Knife web app
- Flame Startpage - Easy startpage and bookmarks page
- Nextcloud - Flexible open source file synchronization and sharing solution
- PhotoPrism - Photos management app
- Prep your host system.
- Follow startup instructions on each of the component readme pages linked in the Components Overview above.
Linux is preferred for a server. I tend to run Debian-based distros, but any Linux distro should work fine. Since stuff is mostly Docker-based, Outpost can also be run on a local workstation as localhost
, including MacOS (partially tested) and theoretically Windows (if you must, not tested, some mods probably necessary). All setup and commands in this repo assume a Linux (Debian) host, so YMMV.
Outline
It's general best practice to run any apps / functions on a separate partition than the root OS.
- Option 1: Partition the hard drive to separate
/
(root) and everything else. At minimum, if you blow through the available storage at least you haven't also crippled the operating system. - Option 2: Mount a separate drive for data.
- Option 3: Mount a shared drive for data, e.g. using NFS. This has the added benefit of separating the data storage function onto a separate server from the apps / services function. But introduces extra complications. It's best suited for user files that need to be shared across systems, whereas databases are better saved on the local file system (e.g.,
/srv
), then properly backed up
I've configured this project to default to Option 2 above. The /srv
directory is assumed to be on a separate drive from the OS.
- Docker is configured (see Docker Daemon Settings below) to use
/srv/docker
as the default location for docker-related files (containers, volumes, logs, etc.) instead of the standard/var/lib/docker
. - Containers and services will by default save persistent data to various folders in
/srv
, as indicated in thetemplate-env
files.
For using NFS to work:
- The NFS server must enable the
all_squash
setting on the export. - The NFS client config must include the configuration options
user
(allow non-root user to mount) andrw
(read-write). - Any user account that needs read-write access to the share, including system users leveraged by containers, must be added to the
nogroup
groupsudo usermod -a -G nogroup <username>
- Environment variables for data storage will need to be updated based on the relevant NFS share location on the Outpost host file system.
Individual services may have additional considerations when relying on NFS storage mounted to the host. These are documented in service readme files.
Install Docker & Docker Compose according to the latest Docker instructions.
Add some default settings to the Docker daemon for log rotation and container privilege restriction.
- Review contents of the daemon.json file in this repo.
- Check if a default
daemon.json
file has already been created by Docker.
ls /etc/docker/daemon.json
- IF a default file does not exist (meaning the above command returns something like
ls: cannot access '/etc/docker/daemon.json': No such file or directory
), THEN:- Copy the
daemon.json
file from this repo to the default docker location
sudo cp ./daemon.json /etc/docker/daemon.json
- Copy the
- ELSE (i.e., a file already exists at
/etc/docker/daemon.json
):- Modify the existing file to add the settings from this repo's version.
Finally, restart the Docker daemon.
sudo systemctl restart docker.service
Create two networks to use for Docker containers. One for the proxy service and one for databases. This allows some segregation of services, so only containers that need to be proxied are exposed to the proxy side of things and only containers that are shared databases or need access to them will have access to the db network.
docker network create proxy_net
docker network create db_net
Created By Mike Owens | GitHub ~ GitLab ~ Mastodon
License: MIT (Covers the config & setup. Apps & services have their own licenses. Hack responsibly.)
This project is built on plenty of help from other online resources and repos. I try to acknowledge them wherever possible, but I'm human so I've probably forgotten some.
- About open source licenses: ChooseALicense.com / Open Source Initiative / Developer's Guide
- https://github.com/DoTheEvo/selfhosted-apps-docker
- Caddy Security plugin: https://authp.github.io/
- https://github.com/docker/awesome-compose