A real-world self-hosting project used to demonstrate the complete path from an application container to a publicly accessible production service.
SYSTEM MAPPublic request → container
InternetHTTPS request
DNSDuckDNS
NginxTLS + reverse proxy
DockerApplication runtime
Current deployment boundary represented from the documented production setup.
The problem
The goal was to run GitHub Readme Stats under personal infrastructure while making the service reproducible, externally reachable and protected by a proper reverse-proxy and TLS setup.
Engineering challenges
Packaging the upstream application for repeatable execution.
Exposing the service safely through a reverse proxy.
Configuring DNS and HTTPS for a public endpoint.
Operating the service on Oracle Cloud rather than relying on a managed application platform.
Deployment architecture
The service is containerized and placed behind Nginx. Nginx provides the public HTTP boundary while the application remains isolated behind the reverse proxy.
The deployment separates application execution from public traffic handling, creating a foundation that can be extended with additional services later.
Client → DNS → TLS endpoint
TLS endpoint → Nginx reverse proxy
Nginx → containerized application
Oracle Cloud provides the host infrastructure
Engineering decisions
01
Dockerized deployment
Context
The upstream application needed to run consistently across development and deployment environments.
Decision
Package the service as a Docker workload.
Rationale
Containerization makes the runtime reproducible and isolates application dependencies from the host.
Trade-offs
Adds container operational overhead.
Requires basic image and container lifecycle management.
02
Nginx as the public boundary
Context
The application should not directly own the public HTTP boundary.
Decision
Place Nginx in front of the application.
Rationale
A reverse proxy creates a clear boundary for routing, TLS termination and future service expansion.
Deployment workflow
The project was built around the practical sequence of containerization, host configuration, reverse proxy setup, DNS and HTTPS rather than treating deployment as an afterthought.
Operational thinking
The project demonstrates the ability to reason about the complete deployment path rather than stopping at a locally working application.
Security boundary
Public traffic terminates at the reverse-proxy layer with TLS. The application is kept behind the proxy instead of being exposed directly.
Evidence
What the project can prove.
DeploymentOracle Cloud
Self-hosted production-style environment
Public endpointHTTPS
TLS-protected external service
InfrastructureDocker + Nginx
Containerized application behind reverse proxy
Lessons learned
Deployment is part of the product, not a final checkbox.
A clear network boundary simplifies future infrastructure evolution.