[blog-image:eyJpZCI6MTI1LCJibG9nX2lkIjo3MSwiZmlsZW5hbWUiOiJkaWFncmFtMi5qcGVnIiwiaW1hZ2Vfd2lkdGgiOiIyMDAwIiwiaW1hZ2VfaGVpZ2h0IjoiOTU2Iiwic2l6ZSI6IiIsImZsdWlkIjoiaW1nLWZsdWlkIiwiY2VudGVyZWQiOiIiLCJjYXB0aW9uIjoiRW1wYXRoeSBQbGF0Zm9ybSBBcmNoaXRlY3R1cmUgVjEifQ==]

Coming soon in the form of new Empathy releases for bdcli and base-docker. The platform features are using the same philosohy as my orginal Empathy MVC - fun, light, simple.  (KISS, DRY).  It's taken a long time to get to this point but the webiste you are viewing right now is running and deployed in this fashion (the same for my other sites) and some of the platform code is yet to be published on github.  It will probably be under "elib-platform".  I still want to do a slight documentation overhaul for bdcli/base-docker to run a new user through the entire deployment of this setup end-to-end in time for these releases. More info coming soon.

Overview:

This architecture is split into four main concerns: build/test, source control and artifacts, edge routing, and production runtime.

Build / Test Environment

A Test/Build server (currently a Raspberry Pi) runs Docker. Inside Docker:

• Jenkins is used for CI/CD orchestration.
• Web app 1 runs as a test or staging instance.

Jenkins is responsible for building, testing, and coordinating deployments, but it does not serve public traffic.

Source Control

A private Git server hosts the application source code.

• The Test/Build server accesses the Git server over SSH.
• No VPN or overlay network is used for Git access.

Container Images and Artifacts

GitLab is used as a central artifact store, specifically for Docker images.

• GitLab hosts a Docker Container Registry.
• Application images are built and maintained using Packer.
• Both the Test/Build environment and the Production environment pull Docker images from this registry.
• The registry acts as the single source of truth for deployable artifacts.

Edge and Routing

Cloudflare is the public-facing entry point for all external traffic. It owns and manages the following hostnames:

• *.tublr.com
• www.tublr.com
• www.mysite.com

Depending on the hostname, Cloudflare routes traffic to different backends:

• Some traffic is routed directly to the Production server.
• Some traffic is routed to an AWS EC2 Proxy server.

The Proxy server runs Caddy directly on the host (not in Docker). Within Caddy:

• www.tublr.com is explicitly handled.
• Requests for that hostname are reverse-proxied to the Test/Build server.

The reverse proxy connection between the Proxy server and the Test/Build server runs over Tailscale. This is the only place Tailscale is currently used in the system.

Production Environment

The Production server runs on AWS EC2 and hosts Docker.

• Docker runs Web app 1 as the production instance.
• Production receives:
  • Public HTTP(S) traffic directly from Cloudflare
  • Deployment actions from the Test/Build server

Production does not receive traffic via the Proxy server.

Deployment Flow

Deployments are initiated from the Test/Build server:

• Jenkins coordinates deployments.
• Production pulls the required Docker image from the GitLab container registry.

Capistrano-style deployments (atomic release switching and fast rollback) are planned, but are not yet implemented.

Design Principles Reflected

• Build, deploy, and runtime concerns are separated.
• Only real network paths are described.
• No aspirational infrastructure is included.
• Artifacts are immutable and centrally managed.
• Public traffic and control traffic are distinct.
• The system is intentionally v1-focused, with broader orchestration (e.g., ECS) reserved for a future iteration.