Building a Self-Hosted Edge Asset Optimization Solution Using Fly.io and Benthos on VPS

Introduction: The Cost and Performance Challenge of Edge Delivery

In the modern digital landscape, user experience is directly tied to performance. Slow loading times translate to abandoned carts, dropped engagement, and lower search engine rankings. A significant portion of any web application's payload consists of static assets—images, videos, and large binary objects. Traditionally, enterprises rely on centralized Cloud Delivery Networks (CDNs) or heavy cloud-native services like AWS CloudFront paired with Lambda@Edge for asset optimization. While powerful, these proprietary solutions introduce substantial egress costs, complex configuration management, and vendor lock-in.

As infrastructure paradigms shift, engineering teams are increasingly looking toward decentralized, self-hosted alternatives that offer the speed of edge computing without the premium price tag. This guide provides a comprehensive blueprint for building your own Edge Asset Optimization (EAO) solution. By strategically combining Fly.io for global edge routing and execution, Benthos (now known as Redpanda Connect) for high-performance stream and asset processing, and a cost-effective Virtual Private Server (VPS) as the primary storage and compute anchor, you can deploy a robust, production-ready asset pipeline.

---

Understanding the Architecture Components

Before diving into the implementation details, it is crucial to understand why this specific stack—Fly.io, Benthos, and a self-hosted VPS—creates a highly synergistic architecture for edge asset processing.

1. Fly.io: The Global Edge Runtime

Fly.io operates by turning standard Docker containers into globally distributed micro-VMs that run on physical hardware close to your users. Instead of routing a user in Tokyo to a data center in Virginia, Fly.io intercepts the request at its nearest Point of Presence (PoP). For asset optimization, Fly.io acts as our intelligent edge gateway, handling TLS termination, basic caching, and lightweight request filtering.

2. Benthos: The Swiss Army Knife of Data Processing

Benthos is an ultra-fast, stateless stream processor written in Go. While frequently utilized for log and event processing, its declarative configuration structure, minimal memory footprint, and native support for HTTP, S3, and image transformation processors make it exceptionally suited for asset optimization pipelines. It allows us to define complex transformation workflows—such as image resizing, format conversion (e.g., JPEG to WebP), and metadata stripping—using a simple YAML file.

3. The Self-Hosted VPS: The Economic Anchor

While the edge handles immediate requests, a robust backend is necessary for persistent storage, heavy cache compiling, and primary origin services. High-performance VPS providers offer massive storage and compute resources at a fraction of public cloud costs. By anchoring our origin architecture on a VPS, we maintain complete ownership of our asset library while controlling operational expenses.

---

The Architecture Workflow Blueprint

To visualize how data flows through this self-built solution, let us examine the lifecycle of a single asset request:

1. The Request Trigger: A user requests an image asset via a localized URL (e.g., [https://assets.mycompany.com/images/hero.jpg?width=800&format=webp](https://assets.mycompany.com/images/hero.jpg?width=800&format=webp)).
2. Edge Interception: Fly.io intercepts the request at the nearest geographic PoP. If the requested asset variant exists in the edge cache, it is served immediately.
3. Benthos Evaluation: If a cache miss occurs, the request is passed to the localized Benthos instance running inside the Fly.io micro-VM.
4. Origin Retrieval & Transformation: Benthos checks the origin VPS for the raw asset. Once retrieved, Benthos dynamically applies the requested transformations (resizing to 800px width and converting to WebP format) on the fly.
5. Delivery and Caching: The optimized asset is returned to the user and simultaneously stored in the edge cache for subsequent requests.

---

Step-by-Step Implementation Guide

Step 1: Configuring Benthos for Asset Transformation

The core intelligence of our optimization pipeline resides within Benthos. We configure Benthos using a declarative YAML structure to accept HTTP requests, fetch origin content, and perform transformations. Below is an illustrative configuration blueprint for our asset processor:

input:
  http_server:
    path: /assets/{asset_id}
    allowed_verbs: [ GET ]

pipeline:
  processors:
    - branch:
        request_map: |
          root.origin_url = "[https://your-vps-origin.com/raw/](https://your-vps-origin.com/raw/)" + meta("v1_html_path_param_asset_id")
        processors:
          - http:
              url: '${! json("origin_url") }'
              verb: GET
        result_map: |
          root.raw_bytes = content()
          root.format = query("format").string().text().fallback("jpeg")
    
    # Image processing logic occurs here based on query parameters
    - image_processor:
        algorithm: lanczos3
        width: '${! query("width").int().fallback(1920) }'
        format: '${! json("format") }'

output:
  sync: {}

Note: Ensure your Benthos binary includes the necessary compilation flags or external plugins required for image manipulation utilities if utilizing advanced graphical transformations.

Step 2: Containerizing and Deploying to Fly.io

To deploy Benthos globally, we wrap the configuration in a Dockerfile and leverage Fly.io’s command-line interface to orchestrate our edge nodes.

Create a Dockerfile in your project directory:FROM jeffail/benthos:latest COPY ./benthos-config.yaml /etc/benthos/config.yaml ENTRYPOINT [ "benthos", "-c", "/etc/benthos/config.yaml" ]

Next, initialize your Fly.io application using the terminal command fly launch. This will generate a fly.toml configuration file. To maximize edge performance, ensure your application configuration defines multiple regions globally to handle user traffic efficiently:

app = "edge-asset-optimizer"
primary_region = "sin"

[http_service]
  internal_port = 4195
  force_https = true
  auto_stop_machines = false
  auto_start_machines = true

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 512

Execute fly deploy to distribute your optimization engines to the global edge network.

Step 3: Setting Up the VPS Origin Server

Your VPS serves as the definitive source of truth (the origin storage). Secure your VPS using Nginx or Caddy to serve the raw, uncompressed assets exclusively to requests originating from Fly.io's secure IP ranges. This prevents malicious third parties from bypassing your edge layer and overwhelming your origin infrastructure bandwidth.

---

Performance and Cost Analysis

Building a self-hosted solution requires evaluating both the operational efficiencies and economic impacts compared to traditional public cloud ecosystems.

Metric / Feature	Traditional Cloud CDN + Serverless Edge	Self-Hosted Fly.io + Benthos + VPS
Egress Bandwidth Pricing	High ($0.08 - $0.12 per GB)	Extremely Low / Unmetered VPS allocation
Vendor Lock-in Risk	Severe (Proprietary APIs & Ecosystems)	Zero (Open-source Benthos, Portable Containers)
Cold Start Latency	Variable (Serverless function overhead)	Negligible (Persistent micro-VM infrastructure)
Customization Granularity	Limited to vendor-approved libraries	Infinite (Fully customizable Go/Benthos pipelines)

---

Conclusion: Balancing Control and Scalability

Constructing a custom Edge Asset Optimization solution using Fly.io and Benthos on a VPS provides engineering teams with an unparalleled combination of performance sovereignty, architectural flexibility, and cost control. By moving resource-intensive media processing to a highly efficient, declarative engine at the edge, you ensure minimal load times for global clients while heavily reducing your infrastructure spending. As modern scaling demands evolve, breaking free from traditional cloud boundaries via open-source tools is no longer just a viable alternative—it is a strategic engineering advantage.