Introduction

Reverse proxies sit at the core of modern infrastructure.

They terminate TLS, expose internal services, enforce security boundaries, and often become the first control point between users and applications.

Despite being a well-understood component, deploying and operating a reverse proxy stack is still more complex than it should be.

This article explores RtProxy, a project designed to simplify reverse proxy and TLS lifecycle management by reducing it to a deterministic, CLI-driven workflow, while maintaining full transparency and control.

The Real Problem

In real-world environments, reverse proxy deployment involves multiple independent concerns:

1. Configuration Management

  • Writing Nginx configuration blocks
  • Managing virtual hosts
  • Handling upstream definitions
  • Ensuring consistency across environments

2. TLS Lifecycle

  • Certificate issuance (ACME / Let’s Encrypt)
  • Renewal automation
  • Handling validation methods (HTTP-01, DNS-01)
  • Secure storage of private keys

3. Operational Concerns

  • Safe reloads
  • Idempotency
  • Error handling
  • Debugging failures

4. Scaling Complexity

As the number of services increases:

  • Configuration sprawl grows
  • Certificate tracking becomes harder
  • Risk of misconfiguration increases
  • Drift becomes inevitable

Existing Approaches

Most solutions fall into three categories:

Manual (Traditional)

  • Direct Nginx config edits
  • Certbot or manual ACME clients

Pros:

  • Full control

Cons:

  • Error-prone
  • Hard to scale
  • Operational overhead

Container-based Automation

Examples:

  • Traefik
  • Nginx Proxy Manager
  • Docker label-driven systems

Pros:

  • Automation built-in
  • Dynamic configuration

Cons:

  • Requires container ecosystem
  • Adds abstraction layers
  • Debugging becomes indirect

Platform-based (Kubernetes Ingress)

Pros:

  • Highly scalable
  • Policy-driven

Cons:

  • Heavyweight
  • Overkill for many environments

RtProxy Design Philosophy

RtProxy intentionally avoids all three extremes.

The guiding principles are:

1. Deterministic Automation

Every action should produce predictable results.

No hidden state.
No dynamic magic.

2. Transparency

All generated configuration should be:

  • Readable
  • Inspectable
  • Debuggable

3. Minimal Dependency Model

Runs on a standard Linux host with:

  • Nginx
  • acme.sh

No orchestration layer required.

4. CLI as Control Plane

Instead of editing config files:

rtproxy add app.example.com http://10.0.0.10:8080

The CLI becomes the single source of truth.

Architecture Overview

RtProxy is essentially a coordination layer between:

  • Nginx (data plane)
  • ACME client (certificate lifecycle)
  • Filesystem (state persistence)

Flow

  1. User issues CLI command
  2. RtProxy generates Nginx configuration
  3. ACME client issues certificate
  4. Files written to disk
  5. Nginx reload triggered

Configuration Model

RtProxy stores state in a structured, file-based approach:

  • Domain → configuration mapping
  • Certificate storage (ACME home)
  • Nginx site definitions

This enables:

  • Easy backup
  • Predictable state recovery
  • Version control (optional)

Nginx Integration

For each domain, RtProxy generates:

  • HTTP server block (for ACME validation)
  • HTTPS server block (for production traffic)

Key aspects:

  • Standardized configuration templates
  • Consistent TLS settings
  • Proper redirect handling (HTTP → HTTPS)

TLS Handling (ACME)

RtProxy leverages acme.sh for certificate management.

Why acme.sh?

  • Lightweight
  • No external dependencies
  • Supports multiple validation methods
  • Works well in automation contexts

Flow

  1. Domain registered
  2. ACME challenge initiated
  3. Certificate issued
  4. Stored locally
  5. Referenced in Nginx config

DNS vs HTTP Validation

RtProxy can support both:

HTTP-01

  • Simpler
  • Requires port 80 exposure

DNS-01

  • More flexible
  • Supports wildcard domains
  • Requires DNS provider integration

Idempotency and Safety

One of the key engineering challenges is ensuring that operations are safe.

RtProxy addresses this by:

  • Checking existing configurations before writing
  • Avoiding duplicate entries
  • Validating syntax before reload
  • Using controlled Nginx reloads

Error Handling

Common failure points:

  • DNS resolution issues
  • ACME rate limits
  • Port conflicts
  • Invalid upstream definitions

RtProxy surfaces errors clearly and avoids partial states.

Security Considerations

TLS by Default

All services are exposed over HTTPS.

Key Management

  • Private keys stored locally
  • Proper file permissions required

Attack Surface

  • Minimal external dependencies
  • Reduced attack surface compared to full platforms

Operational Model

RtProxy is designed for:

  • Single-node deployments
  • Edge environments
  • Lab environments
  • Lightweight production use cases

Performance Considerations

Since RtProxy uses Nginx:

  • High performance
  • Low resource usage
  • Mature and battle-tested

Example Use Case

Deploying an internal service:

rtproxy add grafana.example.com http://10.10.10.5:3000

Result:

  • HTTPS endpoint available
  • Certificate automatically issued
  • No manual config required

Limitations

  • No distributed clustering
  • No built-in monitoring
  • No API layer (yet)

These are intentional trade-offs.

Future Improvements

Potential roadmap:

  • REST API
  • Multi-node support
  • Health checks
  • Observability integration
  • DNS provider plugins

Conclusion

RtProxy is not trying to compete with enterprise platforms.

It solves a different problem:

Making reverse proxy and TLS management simple, predictable, and transparent.

It demonstrates that:

  • Automation does not require complexity
  • Simplicity can scale if designed correctly
  • Infrastructure tooling should reduce cognitive load

Project

https://github.com/LucaBiancorosso/RtProxy