Victoria nextcloud

Production-style Nextcloud self-hosting stack built with Docker Compose, Nginx, PostgreSQL, Redis, rsyslog, BorgBackup and Certbot. The project demonstrates DevOps fundamentals such as internal service networking, reverse proxy configuration, automated backups, restore validation and E2E infrastructure testing with GitHub Actions. **Stack:** Docker Compose, Nextcloud, Nginx, PostgreSQL, Redis, BorgBackup, rsyslog, Certbot, GitHub Actions. **Best for showing:** DevOps, Linux server operations, Docker, backups, restore workflows and infrastructure validation.

View on GitHub →

Documentation

Victoria Nextcloud Stack

A production-style Nextcloud self-hosting stack built with Docker Compose, Nginx, PostgreSQL, Redis, centralized logging, automated backups and full restore validation.

This project was created to demonstrate practical DevOps skills around service orchestration, reverse proxy configuration, internal networking, backup strategy, restore workflows and CI-based infrastructure validation.

Project Summary

next-victoria is a Docker Compose infrastructure project for running a private Nextcloud instance with a production-inspired architecture.

The stack includes:

  • Nextcloud as the main application.
  • Nginx as the only public entry point.
  • PostgreSQL as the database backend.
  • Redis for caching and file locking.
  • rsyslog for centralized logging.
  • BorgBackup and pg_dump for backup strategy.
  • Certbot support for HTTPS provisioning.
  • End-to-end validation with disposable Docker environments.

Unlike a simple docker compose up demo, this project focuses on operational concerns: service isolation, backup and restore workflows, CI validation and migration readiness.

What This Project Demonstrates

This project shows my ability to design and operate a multi-service Linux-based application stack.

Key skills demonstrated:

  • Multi-container orchestration with Docker Compose.
  • Internal and public network separation.
  • Nginx reverse proxy configuration.
  • PostgreSQL integration for a real web application.
  • Redis integration for caching and locking.
  • Centralized logging with rsyslog.
  • HTTPS-ready setup with Certbot.
  • Automated backup strategy using BorgBackup and pg_dump.
  • Full restore workflow validation.
  • End-to-end infrastructure testing.
  • GitHub Actions and Gitea Actions CI validation.
  • Linux server operations and self-hosting practices.

Problem

Self-hosting applications like Nextcloud is not only about starting containers.

A reliable deployment needs to answer questions such as:

  • Which services should be publicly exposed?
  • How should internal services communicate?
  • How are logs collected?
  • How are database and file backups handled?
  • Can the system be restored after failure?
  • Can the deployment be validated automatically?
  • Can the stack be migrated to another server?

This project was built to address those operational concerns in a reproducible way.

Solution

The solution is a Docker Compose stack where only Nginx is exposed publicly, while the rest of the services remain internal.

The stack separates responsibilities between services:

  • nginx handles public HTTP/HTTPS traffic.
  • nextcloud runs the application.
  • postgres stores application data.
  • redis improves caching and file locking.
  • rsyslog centralizes container logs.
  • backups handles scheduled backup jobs.
  • certbot supports HTTPS certificate provisioning.

The project also includes scripts and Makefile commands for backup, restore, validation and migration workflows.

Architecture

                         Public Internet
                              │
                              ▼
                        ┌───────────┐
                        │   Nginx   │
                        │  Reverse  │
                        │   Proxy   │
                        └─────┬─────┘
                              │
                              ▼
                       ┌─────────────┐
                       │  Nextcloud  │
                       │ Application │
                       └─────┬───────┘
                             │
          ┌──────────────────┼──────────────────┐
          ▼                  ▼                  ▼
   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
   │ PostgreSQL  │    │    Redis    │    │   rsyslog   │
   │  Database   │    │ Cache/Lock  │    │ Central Logs│
   └──────┬──────┘    └─────────────┘    └─────────────┘
          │
          ▼
   ┌─────────────┐
   │   Backups   │
   │ Borg + Dump │
   └─────────────┘

Stack

LayerTechnology
ApplicationNextcloud
Reverse ProxyNginx
DatabasePostgreSQL
Cache / LockingRedis
Logsrsyslog
BackupsBorgBackup + pg_dump
HTTPSCertbot
OrchestrationDocker Compose
AutomationMakefile + Shell scripts
CIGitHub Actions / Gitea Actions

Main Features

Docker Compose Stack

The project defines a complete multi-service Docker Compose setup.

Only the Nginx service publishes ports to the host. Internal services such as Nextcloud, PostgreSQL, Redis, rsyslog and backup workers are isolated behind Docker networks.

This helps reduce unnecessary exposure and keeps the deployment structure closer to a real server setup.

Nginx Reverse Proxy

Nginx is used as the public entry point for the application.

It forwards requests to the internal Nextcloud service and allows the stack to support HTTP and HTTPS deployment modes.

This makes the architecture easier to operate behind a domain and prepares it for production-style hosting.

PostgreSQL Database

The stack uses PostgreSQL instead of the default lightweight database options.

This improves reliability and better represents real-world application deployments where database persistence, backup and restore are important.

Redis Integration

Redis is included for caching and file locking.

This is important for Nextcloud deployments because it helps improve performance and avoids locking-related issues when multiple users or background jobs interact with files.

Centralized Logging

The project includes rsyslog to centralize logs from different services.

This makes the stack easier to inspect and debug, especially when running multiple containers together.

Backup Strategy

Backups are handled using:

  • BorgBackup for compressed and deduplicated file backups.
  • pg_dump for PostgreSQL database dumps.
  • Retention policies for managing backup history.
  • Makefile commands for manual backup and restore operations.

The backup system is not only documented; it is also validated through the E2E testing workflow.

Restore Workflow

A backup strategy is incomplete without restore validation.

This project includes a restore workflow that verifies whether the system can recover application files and database state from backup archives.

The restore process is part of the project validation flow.

End-to-End Validation

The project includes an E2E test script that creates a disposable environment, starts the stack, validates services, generates test data, runs backups, restores data and destroys the environment.

The E2E validation checks:

  • Docker Compose configuration.
  • Service startup.
  • Nginx public access.
  • Internal service networking.
  • PostgreSQL availability.
  • Redis availability.
  • Nextcloud availability.
  • Backup generation.
  • Restore workflow.
  • Cleanup after execution.

This makes the project stronger than a simple static infrastructure template.

CI Validation

The repository includes CI workflows for validating the project automatically.

The goal is to make sure the stack can be tested in a clean environment and that backup/restore workflows do not depend only on manual checks.

CI validation helps prove that the infrastructure is reproducible.

Why This Project Matters

This project is valuable because it demonstrates operational thinking.

Many portfolio projects only show application code. This project shows the other side of software delivery: running, protecting, validating and recovering a real service.

It demonstrates that I can work with:

  • Linux-based services.
  • Dockerized deployments.
  • Reverse proxies.
  • Databases.
  • Cache layers.
  • Logs.
  • Backups.
  • Restore operations.
  • CI workflows.
  • Infrastructure documentation.

For backend and DevOps roles, this kind of project shows that I understand how software behaves after deployment.

Technical Decisions

Why Docker Compose?

Docker Compose was used because it is simple, portable and appropriate for small to medium self-hosted deployments.

It allows the complete stack to be defined in one place and makes the environment easier to reproduce.

Why PostgreSQL?

PostgreSQL was selected because it is a reliable production-grade database and commonly used in real deployments.

It also makes backup and restore workflows more meaningful than using a lightweight local database.

Why BorgBackup?

BorgBackup provides deduplication, compression and retention-friendly backup management.

This makes it a good fit for self-hosted services where file data can grow over time.

Why E2E Testing?

Infrastructure projects are easy to document but harder to trust.

The E2E testing workflow helps verify that the stack can actually start, create data, back up data, restore data and shut down cleanly.

This gives the project stronger credibility as a portfolio piece.

Project Status

Current status: Beta

The project is usable as a portfolio-ready DevOps/self-hosting stack. It is not marketed as a drop-in production template for every environment yet.

The current focus is:

  • Improving documentation.
  • Keeping CI validation stable.
  • Refining backup and restore workflows.
  • Making server migration steps clearer.
  • Improving operational safety.

Lessons Learned

This project helped me practice and improve:

  • Designing multi-container service architectures.
  • Separating public and internal services.
  • Working with Nginx as a reverse proxy.
  • Integrating PostgreSQL and Redis with Nextcloud.
  • Creating backup and restore workflows.
  • Writing operational scripts.
  • Validating infrastructure with automated tests.
  • Documenting infrastructure for future maintenance.

Repository

GitHub repository:

https://github.com/dopelDev/next-victoria

Role

My role in this project:

  • Designed the Docker Compose architecture.
  • Configured service networking and exposure.
  • Set up Nginx reverse proxy behavior.
  • Integrated PostgreSQL and Redis.
  • Added centralized logging.
  • Implemented backup and restore workflows.
  • Added E2E validation scripts.
  • Configured CI workflows.
  • Wrote technical documentation.

Professional Value

This project strengthens my profile as a developer who understands not only how to build software, but also how to deploy and operate services.

It supports my positioning in areas such as:

  • Backend development.
  • DevOps fundamentals.
  • Linux server operations.
  • Docker-based deployments.
  • Self-hosted infrastructure.
  • Application reliability.
  • Backup and recovery workflows.

It is especially relevant for roles involving backend systems, infrastructure automation, Docker, Linux, reverse proxies and production support.

Short Description

Production-style Nextcloud Docker stack with Nginx, PostgreSQL, Redis, centralized logs, Borg backups, Certbot support and E2E restore validation.

Tags

Docker
Docker Compose
Nextcloud
Nginx
PostgreSQL
Redis
BorgBackup
Certbot
DevOps
Linux
Self-hosting
Backups
CI
E2E Testing