Executive Summary

Securing software development practices in a cloud-driven world is a must. This blog post launches a series on Traefik, a reverse proxy for building cost-effective, HTTPS-enabled dev environments. Drawing from 20+ years in QA and software development, I’ll illustrate how to set up environments that cut infrastructure costs, meet GDPR compliance, and reduce deployment risks by matching production from the start. With a secure, flexible local setup, Traefik delivers value for CEOs eyeing the bottom line, CTOs planning growth, and tech leads streamlining workflows. Next, I’ll explain why HTTPS in dev matters and how Traefik simplifies it.

TL;DR

Slash SDLC and hosting costs by up to 30% while ensuring compliance with security standards like GDPR.
Speeds dev cycles with faster and more reliable feedback loops.
Align all dev environments from local to production seamlessly.

Why Use HTTPS with Valid Certificates in Local Development Environments?

The Problem: HTTP-Only Local Development.

HTTP was once the go-to for local dev simple, with no certificates and no overhead. We assumed firewalls secured everything pre-cloud, leaving internal HTTP traffic “safe.” But today’s cloud and Zero-Trust reality demands HTTPS everywhere, even locally. Why? QA literature flags key risks:

Security Misalignment: Production uses HTTPS for compliance (e.g., GDPR), while HTTP testing misses security bugs.
Poor feedback loops: Features like HTTP/2 and Secure Cookies require HTTPS, limiting test accuracy.
Third-Party Risks: APIs (e.g., payment gateways) demand HTTPS, risking integration failures with HTTP.
Dev costs: Skipping HTTPS breeds sloppy practices and poor integrations, driving up costs and technical debt.

The Solution: HTTPS with Valid Certificates Locally.

HTTPS with valid certificates in local dev solves these issues. QA & security experts endorse it for the following reasons:

Environment Parity: All the environments match production, with certificates (e.g., mkcert) enabling TLS (TLS ensures encrypted communication), certificate pinning (a security measure that links a host with their expected digital certificate or public key), and encryption like prod.
Improved Test Confidence: Tests HTTPS-only features and edge cases (e.g., expired certs), minimising post-deployment risks.
Seamless Third-Party Testing: Integrates with HTTPS-required APIs, avoiding insecure hacks for a production-ready setup.
QA & Security as Default: Pay it forward, start from QA and security, enforce early certificate and redirect configs, and promote secure-by-design habits.

The QA literature endorses this solution by aligning dev with prod, boosting security, and catching issues early, principles I’ve long advocated. Tools like Traefik and mkcert make it a practical, essential standard for safe online services. Given the challenges of setting up HTTPS in local development, such as managing certificates, ensuring security, and maintaining consistency with production, Traefik is an ideal solution. It automates certificate handling and traffic routing, making secure, HTTPS-enabled dev environments simple to configure and manage.

Functional Example: Traefik reverse proxy for local dev envs

The Git repository vps-traefik-proxy is my practical Traefik (a tool that routes traffic and manages certificates) example of a local development environment with HTTPS. I use this solution for all my online apps and services. This repository is also a playground and a template for any dev team that wants to set up secure and practical development and production environments.

In technical terms, this repository documents and encourages the setup of Traefik v3 on docker-compose for various development, staging, and production environments.

Traefik, known for its ease of integration with Docker and dynamic configuration, can be challenging to configure manually, especially for those new to DevOps or system administration. This challenge is why, in this repository, I will start by focusing on the requirements to set up, test, and publish online projects on Virtual Private Servers (VPSs), specifically on self-hosting to minimise costs. This setup aligns with the needs of indie developers seeking reliable, cost-effective solutions for managing their infrastructure.

Technical Implementation

The repo structure

The repository’s structure includes a ‘docker’ folder with the infrastructure code. This directory has subdirectories for different environments, such as “local”, “staging”, and “prod”, presenting support for multiple development setups. This folder organisation is handy for managing various stages of the SDLC, from local/integration testing to staging and production.

The folder ‘sample_app’ is a demo Docusaurus website, representing the solution a dev team will work on. By the way, Docusaurus is an exceptional solution for implementing Tech-Docs for any organisation. I will write about this topic in a new post.

The Coding environment

Why do I need a devContainer and a docker local env?

Isolation: Keeps the coding setup separate from my messy personal machine.
Consistency: Ensures all devs use the same tools and extensions.
Productivity: Adds Git and VS Code goodies like Copilot.

For more technical details on DevContainers, check my other post How to code with Cypress tests in a reliable environment?

For tech leaders overseeing development environments, the DevContainer configuration in this repository offers a streamlined setup for a “Traefik Proxy Playground.” It leverages Docker Compose to define a ‘dev_env’ service rooted in a workspace at /home/ubuntu/workspace. Key features include:

Git: Git integration via a DevContainers feature, ensuring version control readiness. The config mounts local Git and SSH credentials (e.g., .gitconfig, id_ed25519) into the container for seamless Git operations within the coding environment.
Ports forwarding: Forwarding port 3000 will be added for local access to Traefik or app interfaces.
Extensions: VS Code customisations enhance productivity with extensions like Git Graph, GitHub Copilot, and YAML support, tailored for developers experimenting with Traefik proxies.
Consistency: On shutdown, the environment halts the Compose stack, keeping resources tidy.

This setup is ideal for teams needing a reproducible, isolated coding environment.

The devContainer.json file for this project.

{
	"name": "traefik proxy playground",
	"dockerComposeFile": "../docker/devcontainer/docker-compose.yml",
	"service": "dev_env",
	"workspaceFolder": "/home/ubuntu/workspace",
	"shutdownAction": "stopCompose",
	"features": {
		"ghcr.io/devcontainers/features/git:1": {}
	},
	"mounts": [
		"source=/home/madpad/.gitconfig,target=/home/ubuntu/.gitconfig,type=bind,consistency=cached",
		"source=/home/madpad/.ssh/id_ed25519,target=/home/ubuntu/.ssh/id_ed25519,type=bind,consistency=cached",
		"source=/home/madpad/.ssh/known_hosts,target=/home/ubuntu/.ssh/known_hosts,type=bind,consistency=cached"
	],
	"customizations": {
		"vscode": {
			"settings": {
				"extensions.ignoreRecommendations": true
			},
			"extensions": [
				"mhutchie.git-graph",
				"github.copilot",
				"github.copilot-chat",
				"fabiospampinato.vscode-todo-plus",
				"fabiospampinato.vscode-highlight",
                "redhat.vscode-yaml"
			]
		}
	},
	"forwardPorts": [
		3000
	]
}

The Local dev-env

This environment is the deployment configuration of our solution to enable fast feedback loops while working. The deployment infrastructure code in the docker/local folder comprises several key files, each serving a specific function in the setup process:

Docker Compose Files: The repository includes docker/local/docker-compse.proxy.yml for setting up the local development environment with the Traefik proxy and docker/local/docker-compse.certs.yml for generating self-signed certificates. These files leverage docker-compose to define services, networks, and volumes, automating all the development environment setups.

# Traefik service configuration for HTTPS in docker-compose.proxy.yml

services:
  dev_env:
    build:
      context: .
      # Select the base env setup you want to use.
      #dockerfile: Dockerfile.ubuntu
      dockerfile: Dockerfile.node
    container_name: dev_env
    image: dev_env        
    ports:
      - 3000:3000
    tty: true
    restart: unless-stopped
    volumes:
      - ./../..:/home/ubuntu/workspace
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    command: sleep infinity
    healthcheck:
      test: ["CMD", "pgrep", "sleep"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 5s

Configuration Files: The traefik.yml file, located in docker/local/traefik, contains the static configuration settings, such as log levels, which are crucial for monitoring and debugging. The config/config.yml file is the dynamic configuration for the TLS certificates.

# TLS certs in the dynamic config.yml file
tls:
  certificates:
    - certFile: /etc/certs/_wildcard.testlocalsetup.com.pem
      keyFile: /etc/certs/_wildcard.testlocalsetup.com-key.pem
      stores:
        - default
    - certFile: /etc/certs/_wildcard.sampleapp.com.pem
      keyFile: /etc/certs/_wildcard.sampleapp.com-key.pem
      stores:
        - default
  stores:
    default:
      defaultCertificate:
        certFile: /etc/certs/_wildcard.testlocalsetup.com.pem
        keyFile: /etc/certs/_wildcard.testlocalsetup.com-key.pem
  options:
    default:
      minVersion: VersionTLS12

Environment Management: The .env.dist file, to be copied and amended as .env, provides a template for environment variables. This approach allows developers to customise settings like app names, domain names and secrets tailored to their secured environment.

# Sample .env file with variables for local dev setup
APP="test-app"

# Run the command `echo $(htpasswd -nb user 'password') | sed -e s/\\$/\\$\\$/g` to genereate a random password.
# TRAEFIK_DASHBOARD_CREDENTIALS="user:password"

The technical details are explained below and documented in the README.md file. An outline of this setup operation involves generating certificates using the mkcert tool, launching the Traefik reverse proxy, and finally deploying and dynamically developing our web apps. While working, Traefik logs are monitored at docker/local/traefik/logs, with configurable log levels enhancing the proxy’s operation visibility. This structure supports a streamlined workflow for developers, reducing the need for manual configuration and ensuring consistency across developers, test environments and production.

Setting it up

I have documented all the technical details and commands in the README.md file. As a technical summary, to launch this local development environment, we need to follow the steps below. I assume the host OS has Docker and docker-compose installed, and the developer has basic knowledge of Git.

Clone the Repository: To start cloning the repository, use the command

git clone https://github.com/marcandreuf/vps-traefik-proxy

Configure Environment Variables: Copy the template environment file with cp .env.dist to .env, then edit .env to set the necessary variables. The file includes comments for guidance. This step is crucial for tailoring the setup to the developer’s needs.
Generate Self-Signed Certificates: To generate self-signed certificates, use the command

docker-compose -f docker-compse.certs.yml run --rm mkcert

The certificate files will be created in docker/local/traefik/certs. The root CA located at /docker/local/certs/rootCA.pem must be added to the browser for trusted certificate authorities.

Start the Traefik Proxy: Initiate the Traefik proxy with

docker compose -f docker-compse.proxy.yml up -d

This command starts the proxy service in detached mode. The compose file defines how Traefik routes traffic and manages services, leveraging Docker’s containerisation for ease of management.

Verify the Setup: Verify the setup by accessing the Traefik dashboard or testing the whoami proxied test application. Check that Traefik is running at docker/local/traefik/logs, with log levels configurable in traefik.yml. Everything is working fine with the info log level if there are no log traces.

Test the Whoami app at: https://whoami.testlocalsetup.com
Test the Traefik dashboard at: https://tf-dashboard.testlocalsetup.com
Test the Docusaurus demo app at: https://docusaurus.sampleapp.com

We use different sample domain names. None of those domains are actual domains. They are just placeholders for the local development environment. We configure the exact domain names only for the staging and production environments.

This process ensures a functional Traefik proxy setup for local development with minimal manual intervention, though there is still much room to customise and automate this further. From here, developers can work on adding their applications and configure Traefik docker-compose labels to route traffic accordingly. However, this is beyond this initial setup, and I will cover it in future blog posts.

Work in Progress

Notes on the secure Staging and Prod environments

The staging and prod environments are still work in progress. As I write this post, I am further implementing the ‘vps-traefik-proxy’ repository and validating the core ideas with my online published solutions.

My assumptions and guidelines for these environments are that scaling a Docker Compose-based local dev environment into staging and production is straightforward with the right tools. Of course, the staging setup will depend on the test intention of the staging environments. Not all the staging environments need to be the same or a replica of prod, but I do not want to digress too much from the infrastructure topic. Please ask in the comments or email me how to prepare CI/CD environments if you need more details.

While docker-compose is an initial performant solution for small to medium projects, we might want to use more heavy tools like Kubernetes or Amazon SST for staging and production. However, the Traefik configuration principles will mostly apply to whatever deployment technology we want.

For staging, I would stick with Docker Compose as much as possible for simplicity. I would then jump to Docker Swarm, Kubernetes, Amazon SST or similar solutions for multi-node testing, using CI/CD pipelines (e.g., GitHub Actions) to automate deployments. With any underlying deployment technology, we would generate self-signed certificates on the fly to keep test domains flexible and avoid third-party dependencies like Let’s Encrypt or Cloudflare DNS.

For production, we would start with Docker Compose (yes, we do not need to worry about scalability from day one) and later switch to Kubernetes, Amazon, or another for robust scaling. Think auto-scaling and rolling updates. I have a performant VPS with Traefik reverse proxy pairing with Let’s Encrypt certificates via Cloudflare DNS for trusted, zero-maintenance SSL certificates.

This progression of secure development environments provides consistency across settings while balancing flexibility and scalability. Curious about the details? Future posts will dive into orchestration, pipelines, and cert automation. In this post, I am sharing the initial steps for setting up a secure local development environment for web/API services.

The core principle is that aligning the local, staging, and prod configuration environments as much as possible will simplify the testing, minimise human errors, minimise operational costs, and enhance the end user’s quality.

Conclusion and Implications

This setup cuts costs, boosts security, and aligns dev with prod, which is perfect for lean teams. The vps-traefik-proxy repository offers an initial practical solution for developers seeking to simplify the Traefik v3 proxy setup for a secure local development environment. Leveraging docker-compose reduces complexity, enhances manageability, and supports self-hosting to minimise infrastructure costs.

Including certificate generation and environment-specific configurations adds to its utility, making it a robust tool for austere, secured local development environments for web application development. This setup mainly benefits those with little DevOps experience, providing a clear path to cost-efficient web infrastructure.

Next, we’ll scale this repo to staging and production with CI/CD.

Shameless plug: Partnering for Success

Here at the Test Automation Agency, we are specialists TestOps. Our services include Test Automation, Integrated Test Frameworks and CI/CD optimisation. Let’s work together to build secure and scalable environments to maximise developers’ productivity through happy coding.

Please share, ask, or correct anything in the comments below. At the TAA, we are open to helping you set up secure and high-quality development environments.

Connect with us using the header button now and get started on preparing your competitiveness with top-tier TestOps.

Many thanks for reading.

Traefik: Your Solution to Secure, Scalable Dev Environments