All projects
Infrastructure / Cloud / Developer ToolsSHIPPED

GitHub Readme Stats Deployment

Production infrastructure & self-hosting

A production-style deployment of GitHub Readme Stats, hardened behind Nginx with TLS and hosted on Oracle Cloud.

Live demoGitHubProduction Deployment Architect

Overview

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.
  • Reproducibility matters even for a small service.

What comes next

  • Automate more of the deployment lifecycle.
  • Add deeper service monitoring and alerting.
  • Document recovery and rollback procedures.