everywall/ladder: Self-Hosted Proxy for Debugging Paywalls & CORS

everywall/ladder: Self-Hosted Proxy for Debugging Paywalls & CORS

Modern web development^{↗ Bright Coding Blog} involves navigating increasingly complex content delivery systems. Paywalls, cross-origin resource sharing (CORS) restrictions, and browser security headers like Content-Security-Policy can obstruct legitimate debugging, testing, and research workflows. Developers building scrapers, testing access controls, or analyzing how sites serve content to different user agents need controlled environments to observe these behaviors without fighting browser constraints at every step.

everywall/ladder addresses this gap directly. This open-source Go proxy lets you strip, modify, and inject headers and HTML on the fly—giving you a manipulable middle layer between your client and target websites. Whether you're verifying how a paywall responds to different user agents or removing CORS blocks from API responses during local development, everywall/ladder provides a self-hosted alternative to services like 12ft.io, keeping your traffic under your own infrastructure.

What is everywall/ladder?

everywall/ladder is an HTTP web proxy written in Go, maintained by the everywall organization on GitHub. With 8,712 stars and 508 forks as of its last commit on July 10, 2026, it has gained meaningful traction among developers who need programmable request/response modification. The project is licensed under the GNU General Public License v3.0, ensuring it remains free and open-source.

The tool positions itself explicitly as a "developer tool for testing and analyzing paywall implementations and content delivery behavior on modern websites." It allows simulation of different client environments—browsers, crawlers, specific user agents—and observation of how content delivery changes under those conditions. This makes it useful for debugging paywall configurations, verifying access controls, inspecting HTTP headers, and ensuring consistent behavior across different user agents.

Importantly, the maintainers frame ladder as intended for "legitimate testing, research, and quality assurance purposes only," emphasizing compliance with applicable laws and target website terms of service. This isn't a tool for circumventing paid content unlawfully; it's infrastructure for understanding how content delivery mechanisms work.

The proxy operates by intercepting requests, applying configurable modifications, forwarding to the target site, then applying response modifications before returning to the client. This architecture enables both request transformation (headers, URL rewriting) and response transformation (header stripping, HTML/JS/CSS injection).

Key Features

everywall/ladder's feature set reflects its dual purpose as both a debugging utility and a programmable proxy infrastructure:

Header Manipulation: Remove or modify CORS headers from responses, assets, and images. Strip or override Content-Security-Policy and other security headers that might block local development or testing scenarios. Set custom User-Agent strings and X-Forwarded-For IPs to simulate different client types.

Content Injection & Modification: Inject custom HTML, CSS, or JavaScript^{↗ Bright Coding Blog} into pages at specified DOM positions (head, or CSS selectors). Use regex-based rules to rewrite page content dynamically. This enables testing how sites behave with modified resources or removed tracking scripts.

Domain-Based Rulesets: Apply granular rules per-domain or per-path through YAML configuration. Rules can modify request URLs (query parameters, domain parts, paths), set domain-specific headers, and toggle features like FlareSolverr integration for specific origins only.

Operational Modes: Browse sites interactively through a web form interface, fetch raw HTML directly via /raw/ endpoints, or use the API programmatically. Expose your ruleset to other ladder instances for distributed team usage.

Deployment Flexibility: Available as Docker^{↗ Bright Coding Blog} containers (amd64, arm64), Linux/Mac/Windows binaries, and Helm charts for Kubernetes. Optional Basic Auth protects publicly exposed instances. Access logging and domain allowlisting provide operational control.

FlareSolverr Integration: For sites protected by Cloudflare or similar anti-bot challenges, ladder can delegate to a FlareSolverr instance running a headless browser to solve JavaScript challenges and return session cookies.

Use Cases

Paywall Configuration Testing: Publishers and developers building paywall systems can use ladder to verify how their content appears to different user agents. By simulating Googlebot or other crawlers, teams can confirm that metered paywalls, hard paywalls, or registration walls behave as intended—without relying on external services that may cache or modify responses unpredictably.

CORS-Blocked API Development: When integrating with third-party APIs that lack proper CORS headers, frontend developers often face blocked requests during local development. Ladder strips these restrictions at the proxy layer, allowing uninterrupted development while maintaining awareness that production deployment requires proper CORS configuration on the API side.

Content Delivery Research: Academics, journalists, and compliance teams analyzing how websites personalize content can use ladder's header and IP spoofing capabilities to observe cloaking behavior—where sites serve different content to search engines versus regular browsers. The tool documents this use case explicitly while noting that many sites employ fingerprinting beyond simple header checks.

Automated Testing Infrastructure: QA teams can integrate ladder into CI pipelines to test paywall flows, subscription funnels, or content access controls under reproducible conditions. The API and raw HTML endpoints enable headless testing without browser automation overhead for scenarios where proxy-level manipulation suffices.

Anti-Tracking & Content Sanitization: The regex and injection capabilities allow stripping tracking scripts, advertisements, or third-party content from pages. While not the primary design goal, this enables cleaner testing environments and reduced noise when analyzing core page functionality.

Installation & Setup

The maintainers provide multiple installation paths. Choose based on your operational environment:

Binary Installation

# 1) Download latest release from GitHub
# Visit: https://github.com/everywall/ladder/releases/latest

# 2) Unpack and run with default ruleset
./ladder -r https://raw.githubusercontent.com/everywall/ladder-rules/main/ruleset.yaml

# 3) Open browser to default address
# http://localhost:8080

The -r flag specifies the ruleset source, which can be a URL, local file path, or directory of YAML files.

Docker (Single Container)

docker run -p 8080:8080 -d \
  --env RULESET=https://raw.githubusercontent.com/everywall/ladder-rules/main/ruleset.yaml \
  --name ladder \
  ghcr.io/everywall/ladder:latest

This pulls the latest container image, exposes port 8080, and configures the default community ruleset via environment variable.

Docker Compose

# Download compose configuration
curl https://raw.githubusercontent.com/everywall/ladder/main/docker-compose.yaml \
  --output docker-compose.yaml

# Start services
docker-compose up -d

The compose file likely includes additional service configuration; review it before deployment for production use.

Helm (Kubernetes)

For Kubernetes deployments, consult the README.md in the helm-chart subdirectory of the repository. This provides chart values and deployment patterns for cluster environments.

Critical Security Warning

The README explicitly warns: enable Basic Auth for any publicly accessible instance. Without authentication, anyone can use your proxy, potentially for illegal activity, with legal liability falling on the operator. Set USERPASS=admin:securepassword or equivalent.

Real Code Examples

Basic Proxy Usage

The simplest interaction uses direct URL appending:

http://localhost:8080/https://www.example.com

Or via the API endpoint for programmatic access:

curl -X GET "http://localhost:8080/api/https://www.example.com"

The /api/ prefix returns the processed response with all rules applied, suitable for integration with scripts or testing tools.

Raw HTML Fetching

For scenarios requiring unrendered source:

http://localhost:8080/raw/https://www.example.com

This bypasses browser rendering and returns the modified HTML directly—useful for diffing, archiving, or automated analysis.

Bookmarklet for Quick Access

javascript:window.location.href="http://localhost:8080/"+location.href

Save this as a browser bookmark. Clicking it while viewing any page redirects through your ladder instance automatically.

Ruleset Configuration Example

The README provides this comprehensive YAML structure:

- domain: example.com          # Includes all subdomains
  domains:                     # Additional domains to apply the rule
    - www.example.de
    - www.beispiel.de
  headers:
    x-forwarded-for: none      # override X-Forwarded-For header or delete with none
    referer: none              # override Referer header or delete with none
    user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
    content-security-policy: script-src 'self'; # override response header
    cookie: privacy=1
  regexRules:
    - match: <script\s+([^>]*\s+)?src="(/)([^"]*)"
      replace: <script $1 script="/https://www.example.com/$3"
  injections:
    - position: head # Position where to inject the code
      append: |      # possible keys: append, prepend, replace
        <script>
          window.localStorage.clear();
          console.log("test");
          alert("Hello!");
        </script>

This rule matches example.com and all subdomains, plus two additional domains. It strips identifying headers, sets a custom user agent, modifies CSP, rewrites script source paths to route through the proxy, and injects JavaScript into the document head. The append, prepend, and replace keys control injection behavior.

FlareSolverr Integration Rules

- domain: cloudflare-protected-site.com
  useFlareSolverr: true  # Enable FlareSolverr for this domain
  headers:
    user-agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
    accept: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"

This selectively enables headless browser challenge-solving only for domains that require it, avoiding the performance penalty on regular requests.

Advanced Usage & Best Practices

Performance Considerations: The PREFORK environment variable spawns multiple server instances when set to true, improving throughput for high-volume scenarios. However, the default single-instance mode suffices for individual development use.

Ruleset Management: The EXPOSE_RULESET=true setting makes your configuration available to other ladder instances via the /ruleset endpoint. This enables team consistency but consider whether your rules contain sensitive domain targets or proprietary logic before exposing.

Domain Restrictions: Combine ALLOWED_DOMAINS (explicit comma-separated list) with ALLOWED_DOMAINS_RULESET (boolean to include ruleset domains) to prevent proxy misuse. If both are empty, no restrictions apply—acceptable for localhost-only operation, dangerous for exposed instances.

FlareSolverr Economics: Only enable useFlareSolverr for domains that actively require it. The headless browser adds significant latency and resource consumption. Monitor your FlareSolverr instance's health independently; ladder will fail requests if the solver is unreachable.

Development Workflow: For local ladder development, the project uses cosmtrek/air for live reloading. The frontend form uses Tailwind CSS^{↗ Bright Coding Blog} classes built via pnpm—run pnpm build after modifying form.html styles.

Comparison with Alternatives

ladder complements rather than replaces FlareSolverr—the README explicitly notes they can be used together. The hosted alternatives offer convenience but sacrifice configurability and data control. For teams with compliance requirements or need for reproducible testing environments, self-hosting with ladder provides necessary control.

FAQ

Is everywall/ladder free to use? Yes, licensed under GNU GPL v3.0. No commercial licensing is mentioned in the README.

What Go version is required? The README doesn't specify minimum Go version for building, but displays a go.mod version badge. Check the repository for current requirements.

Can ladder bypass all paywalls? No. The README explicitly states it doesn't circumvent advanced protections like fingerprinting, rate limiting, or behavioral analysis. It observes and modifies visible delivery mechanisms.

Is Windows binary production-ready? The Windows binary is marked "untested" in the feature list. Linux and macOS binaries are the primary supported platforms.

How do I protect a public instance? Set USERPASS=username:password. The README emphasizes this is mandatory for public exposure.

Can I use my own ruleset file? Yes. RULESET accepts local file paths, directories of YAML files, or remote URLs.

Does ladder store proxied content? No evidence of caching in the README. It operates as a real-time proxy with optional access logging of fetched URLs.

Conclusion

everywall/ladder fills a specific niche in the developer tooling landscape: programmable, self-hosted HTTP proxying for legitimate content delivery research and debugging. Its 8,712 GitHub stars indicate genuine utility for developers who've encountered the friction of CORS-restricted APIs, paywall testing requirements, or need to observe how sites behave under different client presentations.

The tool is best suited for: backend developers integrating with third-party services, QA engineers testing access control flows, researchers analyzing web content delivery, and DevOps^{↗ Bright Coding Blog} teams needing controllable proxy infrastructure. It's not a magic bypass for all anti-bot systems, nor a replacement for proper API CORS configuration—but it is a precise instrument for understanding and manipulating HTTP interactions.

If your work involves debugging how websites serve content to different clients, or you need CORS flexibility without browser extension hacks, explore everywall/ladder on GitHub and evaluate whether self-hosted proxy control fits your workflow.