Skip to content

seventrees-dev/server-infrastructure

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

SevenTrees Infrastructure Documentation

Overview

This documentation provides a practical guide to the SevenTrees server infrastructure. Our setup consists of a small, energy-efficient home server running multiple containerized applications using Docker Compose. The server hosts file storage, workflow automation, databases, and web services accessible through a secure reverse proxy.

Quick Navigation

Server Specifications

We use a compact, fanless server based on the Intel N100 platform, providing reliable performance while remaining energy-efficient and silent.

Hardware & Software

  • Platform: MeLE QuieterDL Fanless Mini PC
  • CPU: Intel(R) N100
  • GPU: Intel(R) UHD Graphics
  • RAM: 16 GB (15.7 GB usable)
  • Storage: 477 GB SSD (C:\ drive with ~375 GB free space)
  • Operating System: Windows 11 (Build 24H2 - 26100)

This setup can handle our workload for now, but is not something we plan to use permanently. In the future we plan to expand our servers to handle different microservices.

Server Network Infrastructure

Network Location

The server is currently hosted in Hendrik-Jan's home network within a dedicated subnetwork.

Public IP Address: 195.85.188.190

Network Architecture

Internet 
    ↓
Home Router/Firewall
    ↓
Subnetwork (195.85.188.190)
    ↓
SevenTrees Server (Windows 11)
    ↓
Docker Containers (Internal Network)

The server sits behind a home router with port forwarding configured to allow external access to specific services. Services running inside Docker containers communicate through internal Docker networks, while select ports are exposed for external access.

Accessing the Server

Current Access Method: Remote Desktop (RDC)

How it works: Remote Desktop Connection (RDC) is currently configured with port forwarding, allowing remote access to the Windows 11 server through the public IP address 195.85.188.190.

Access procedure:

  1. Open Remote Desktop Connection client
  2. Connect to: 195.85.188.190:[RDC_PORT]
  3. Enter credentials
  4. Access full Windows desktop environment

Security Considerations & Future Plans

Current state: RDC is publicly accessible through port forwarding, which poses security risks.

To-Do (Planned improvements):

  • Migrate to SSH: Implement SSH access for more secure, lightweight remote management
  • IP Allowlist for RDC: Restrict RDC access to a whitelist of trusted IP addresses
  • VPN Solution: Consider implementing a VPN for secure remote access to the entire network

Until these improvements are implemented, ensure RDC uses strong passwords and consider enabling Network Level Authentication (NLA).

Deploying Applications with Docker Compose

What is Docker Compose?

Docker Compose is a tool for defining and running multi-container Docker applications. Instead of manually starting each container with complex command-line arguments, you define all your services, networks, and volumes in a single docker-compose.yml file.

Benefits:

  • Declarative configuration: Define your entire infrastructure as code
  • One-command deployment: Start/stop all services with a single command
  • Reproducibility: Same configuration works on any machine with Docker
  • Version control: Track infrastructure changes in Git
  • Networking: Automatic network creation between containers
  • Dependencies: Define startup order and health checks

Main Infrastructure Repository

The main infrastructure repository contains shared services that other applications depend on:

Repository: [https://github.com/arvind-nohar/Infrastructure/tree/main]

Services included:

  • Caddy: Reverse proxy and web server with automatic HTTPS
  • Zipline: File storage and sharing service
  • PostgreSQL: Database for Zipline

Deploying a New Application

Step 1: Clone the repository

git clone [repository-url]
cd [repository-folder]

Step 2: Start all services

docker-compose up -d

The -d flag runs containers in detached mode (background), allowing you to close the terminal while services continue running.

Verification:

docker-compose ps

Deploying Code Changes

When updates are made to the repository (configuration changes, new services, updated images):

Step 1: Stop all services

docker-compose down

Step 2: Pull latest changes

git pull origin main

Step 3: Restart services with new configuration

docker-compose up -d

Docker Compose will automatically:

  • Pull new container images if versions changed
  • Recreate containers with updated configuration
  • Preserve data in volumes (databases, uploaded files)

Other Docker Compose Stacks

Our infrastructure includes several independent Docker Compose stacks, each in their own repository:

Application Purpose Repository
sales-database PostgreSQL database for sales data [https://github.com/arvind-nohar/salestool-db]
n8n Workflow automation platform [https://github.com/arvind-nohar/n8n-autoscaling]
seven-virtualassistant Virtual assistant application [https://github.com/mhyhu/bot_press]
seven-virtualassistant-database Database for virtual assistant [Link to seven-virtualassistant-database repo]

Each application has its own docker-compose.yml file and follows the same deployment process described above.

Caddy Web Server

What is a Web Server?

A web server is software that receives HTTP/HTTPS requests from clients (browsers, apps) and responds with the requested content. It acts as the entry point for all web traffic coming to your domains.

Example: When someone visits https://seven.seventrees.nl, their browser sends a request to our web server, which then serves the appropriate content. The primary domain is seventrees.nl and using dns we can create subdomains (e.g. testing.seventrees.nl) that point to the server ip. When users visit one of the subdomains, they get redirected to the server ip and the internal port that is proxied to that subdomain. This way, users are able to see our self-hosted applications on their own network. See Reverse Proxy for more information. Below a list of registered subdomains that point to the server ip:

Registered subdomains

Subdomain Internal port Active
seven.seventrees.nl :5000 Yes
testing.seventrees.nl :6789 Yes

Why Caddy?

Caddy is a modern, easy-to-configure web server that offers several advantages:

  • Automatic HTTPS: Automatically obtains and renews SSL/TLS certificates from Let's Encrypt
  • Simple configuration: Human-readable Caddyfile instead of complex syntax
  • Built-in reverse proxy: Route traffic to different backend services
  • Modern defaults: Security best practices enabled out of the box

Reverse Proxy Functionality

A reverse proxy sits between clients and your backend services, forwarding requests to the appropriate application.

How it works:

Client Request (https://seven.seventrees.nl)
    ↓
Caddy Reverse Proxy
    ↓
Routes to → Backend Service (host.docker.internal:5000)

Benefits:

  • Single entry point for all services
  • One SSL certificate for multiple backend services
  • Hide backend server details from public
  • Load balancing and security features

TLS Encryption

What is TLS?: Transport Layer Security (TLS) encrypts data between the client and server, preventing eavesdropping and tampering.

Why it's important:

  • Privacy: Prevents anyone on the network from reading data in transit
  • Authentication: Verifies you're connecting to the legitimate server
  • Integrity: Ensures data hasn't been modified during transmission
  • Trust: Modern browsers warn users about unencrypted sites
  • Compliance: Required for handling sensitive data

Caddy automatically handles TLS certificate management, ensuring all our domains use HTTPS without manual intervention.

Our Caddy Configuration

Domains managed:

  • seven.seventrees.nl → Seven virtual assistant (port 5000)
  • testing.seventrees.nl → n8n automation platform

Caddy automatically:

  • Obtains SSL certificates for both domains
  • Renews certificates before expiration
  • Redirects HTTP to HTTPS
  • Proxies requests to backend services

Accessing Services Remotely

Port Forwarding Basics

Port forwarding configures your router to forward incoming traffic on specific ports to your internal server. This allows external access to services running on the private network.

How it works:

Internet Request → Router (195.85.188.190:PORT) → Forwards to → Server Internal IP:PORT

Current Port Exposures

Some services are directly accessible through exposed ports:

Service Port Environment Public Access
PostgreSQL (Sales DB) 6543 Development Yes (direct)
PostgreSQL (Sales DB) 6544 Production Yes (direct)
HTTP 80 - Yes (Caddy)
HTTPS 443 - Yes (Caddy)
RDC 3389 - Yes (port forwarded)

Security Concerns with Direct Database Exposure

Current issue: The PostgreSQL sales database is directly exposed to the internet on ports 6543 and 6544. This creates security risks:

  • Database is accessible from any IP address
  • Relies solely on username/password authentication
  • Vulnerable to brute force attacks
  • No additional layers of security

To-Do (Migration plan):

  • Migrate to self-hosted n8n: Move n8n from external hosting to our local server
  • Close database ports: Remove port forwarding for 6543 and 6544
  • Internal network only: Services will communicate through Docker's internal network
  • Access through Caddy: Any necessary external access goes through authenticated web interfaces like pgadmin

Once migration is complete, all services will communicate securely within the local Docker network, with only Caddy (ports 80/443) exposed to the internet.

Specific scenarios

Server is down

There is a high probability that the server is down when one or more of the below cases is true:

  • The Seven virtual assistant is not loading on the https://seventrees.nl website
  • You can't connect to the postgresql sales databases
  • The n8n workflows are failing on the postgresql nodes with errors messages like "connection to database failed"

Starting the server after downtime

The server is configured to auto-run the docker containers and custom scripts for all our applications. This way when only have to start the server without manually turning on every container/application. If you observed and confirmed one of the above scenarios follow the below debugging steps:

  1. Open 'Remote Desktop Connection' application in Windows
  2. Input the following details: Computer: 195.85.188.190 User name: seventrees
  3. Press connect
    • (a) If the connection is successful you should be prompted to enter your credentials. The username should already be filled in with seventrees, if not input it yourself and click OK
    • (b) If the connection failed you should check with Hendrik-Jan directly and the Dev team should be notified. Below some possible causes:
      • A network issue at Hendrik-Jan's home network
      • Power outage at the server location
      • Server died (let's hope not)
  4. In case of 4a, you should now have access to the remote desktop of the server. After outage, it could take a while to start everything up
  5. Check if docker and terminal scripts are started after 10 minutes
  6. Confirm that you can access the seven virtual assistant through https://seventrees.nl

To-Do List

Security Improvements

  • Implement SSH access for server management
  • Configure IP allowlist for RDC access
  • Consider VPN solution for remote access
  • Close PostgreSQL ports 6543/6544 after n8n migration

Infrastructure Improvements

  • Migrate n8n to self-hosted instance on local server
  • Move database connections to internal Docker network
  • Implement automated backup system for databases
  • Set up monitoring and alerting for service health
  • Register subdomains for n8n and Zipline

Documentation

  • Add repository links to each Docker Compose stack
  • Document backup and recovery procedures
  • Create runbooks for common maintenance tasks
  • Document network architecture diagram

Future Considerations

  • Evaluate moving to Linux-based server OS
  • Implement container resource limits
  • Set up centralized logging
  • Consider container orchestration (Kubernetes/Swarm) as we scale

Quick Reference Commands

Docker Compose Commands

# Start all services
docker-compose up -d

# Stop all services
docker-compose down

# View running containers
docker-compose ps

# View logs
docker-compose logs -f [service-name]

# Restart specific service
docker-compose restart [service-name]

# Pull updated images
docker-compose pull

# Remove everything including volumes (⚠️ deletes data)
docker-compose down -v

Deployment Workflow

Important: you should always be in the directory of the repo containing the docker-compose.yml for that specific project, you cannot deploy containers from a different project in the same folder.

# Deploy new application
git clone [repo-url]
cd [repo-folder]
docker-compose up -d

# Deploy updates
docker-compose down
git pull origin main
docker-compose up -d

Support

For questions or issues related to this infrastructure:

Contact: arvind.nohar@seventrees.nl

Resources:

Last Updated: October 2, 2025

About

This repo contains the server infrastructure

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published