Local development infrastructure: Self-hosting with Docker containers
Learn how to build a productivity ecosystem by running your own services in containers. Reduce dependency on third-party tools and gain full control over your data and workflows.
Summary
- Running tools in local containers eliminates latency and recurring SaaS subscription costs.
- Docker Compose centralizes configuration and ensures environment portability across development machines.
- Tools like IT-Tools and Stirling-PDF provide essential utilities that respect data privacy by processing files locally.
- Implementing SearXNG enables queries across multiple search engines without aggressive tracking from large corporations.
- Volume persistence is the fundamental requirement for ensuring critical data is not lost when recreating containers.
The concept of local infrastructure for developers
Cloud-based tool centralization has improved collaboration, but it has brought challenges regarding privacy, reliance on stable connections, and subscription costs. Running daily tools in your own containers, which are isolated software instances containing only what is needed to run an application, allows developers to maintain rigorous control over their working environment. Instead of using online PDF converters, you can instantiate a local service that processes your documents without sending them to external servers.
Deploying IT-Tools, Stirling-PDF, and SearXNG
To build this infrastructure, we use Docker Compose, a tool that reads a text file to orchestrate multiple containers at once, making it easy to spin up your entire tool stack with a single command. IT-Tools solves common developer tasks, such as JSON manipulation and encryption; Stirling-PDF acts as a Swiss Army knife for documents; and SearXNG functions as a meta-search engine that aggregates anonymized results.
Environment setup with Docker Compose
Below, we present an example configuration file to run these tools in an isolated and organized way on your local machine or a dedicated server on your internal network. Note that we use volumes to ensure your documents and configurations persist even after the containers are restarted.
services: stirling-pdf: image: frooodle/s-pdf:latest ports: - '8080:8080' volumes: - ./data:/data it-tools: image: corentinth/it-tools:latest ports: - '8081:80' searxng: image: searxng/searxng:latest ports: - '8082:8080' volumes: - ./searxng:/etc/searxngVolume management and persistence
In container-based systems, data persistence is vital because the container lifecycle is ephemeral, meaning it can be deleted and recreated without warning. By mapping a directory from your host system into the container via volumes, you ensure that the files you manipulate in Stirling-PDF, for example, remain intact on your hard drive, regardless of the application's state.
Considerations for internal networks and security
When running these services, it is important to isolate them in internal virtual networks to avoid unnecessary exposure. Using a reverse proxy, such as Caddy or Nginx Proxy Manager, is recommended if you plan to access these tools through user-friendly domains or via HTTPS within your local network. This not only professionalizes access but adds authentication layers that protect tools that do not originally have native logins.
The value of control over your ecosystem
By building your local lab, you become less dependent on third-party failures and improve the execution speed of repetitive tasks. Container infrastructure is not just for software production but for optimizing the engineer's own daily routine. Investing time in initial setup pays off quickly through the autonomy and privacy gained by keeping your work tools under your own digital roof.