Fil Beam: Hosting dApps

Overview

Filecoin Beam proposes here a reliable hosting solution for decentralized applications (dApps) stored on Filecoin Onchain Cloud (FOC) with high SLAs and competitive pricing. This solution will serve static websites via IPFS while managing DNS records, similar to how Fleek previously operated in this space, but with FWSS under the hood as the storage layer, and Filecoin Beam as the retrieval layer.

Background

The Aerodrome team is seeking an alternative to eth.limo, as eth.limo will not meet their SLA requirements even at increased cost. eth.limo also doesn’t support custom domains, only eth.limo ones. This presents an opportunity for Filecoin Beam to capture market share in the dApp hosting space.

Key Context:

  • Fleek previously offered this service for IPFS-hosted static websites, why did they pivot?
  • Initial customer signal from Aerodrome team
  • Need to validate broader market demand

Goals & Objectives

Primary Goal: Enable website builders to deploy and host dApps on FOC with enterprise-grade reliability.

Key Objectives:

  • Provide or describe deployment workflow (e.g., GitHub Actions integration)
  • Offer seamless DNS configuration with ENS integration
  • Deliver high SLA guarantees that exceed existing solutions
  • Ensure payment tracking for storage and egress

Success Criteria

  • Successfully deploy and serve Aerodrome's dApp with required SLAs
  • Match the SLAs of the underlying services: FWSS and Filecoin Beam
  • Complete deployment workflow in 1 hour or less
  • Sign 3-5 additional customers within 3 months post-launch

User Stories

As a website builder,

I want to deploy my dApp to FOC via a simple CI/CD workflow

So that I can automate deployments without manual intervention

As a website builder,

I want to configure my DNS records with clear guidance

So that my dApp is accessible via my custom domain, not just eth.<tld>

As a website builder,

I want to verify my DNS configuration is working correctly

So that I can troubleshoot issues before going live

Functional Requirements

FR1: Deployment

  • FR1.1: Website builders can deploy a repo contain a static website to FOC and receive an IPFS CID in return
  • FR1.2: Deployment could be executable via GitHub Actions
  • FR1.3: System must confirm successful storage on FOC with CID verification
  • FR1.4: System must inform builder of which step in the process has failed

FR2: IPFS Lookup Integration

The IPFS CID must be written to ENS and linked to the dApp's domain name.

Option 1: ENS Universal Domain Support

  • Support writing to ENS for any domain name
  • Allow builders to use their existing domains
  • Note: This requires builders to have an account with Filecoin Beam

Option 2: ENS Managed TLD Approach

  • Purchase domain eth.<new TLD>
  • Host IPFS CIDs stored in ENS (e.g., vitalik.eth) at corresponding subdomains (vitalik.eth.<new TLD>)
  • Constraint: Only serve websites stored and served via FOC to ensure payment tracking for egress and storage
  • Note: eth.limo doesn’t require the builder to create an account. It just works if you set up the ENS record correctly and store your content on a supported IPFS provider.

Option 3: DNS Link Universal Domain Support

  • When builder sets up their DNS records, they also submit the IPFS CID into the UI (or this happens automatically). We then create a DNS Link record in our DNS.
  • This removes the dependency on ENS, and no need to pay for a ENS transaction, which removes the need for a user to have some ETH.

Note: Serving data from non-FOC IPFS providers is out of scope

FR3: DNS Management UI

Note that this section is only needed if we go for Option 2 above.

  • FR3.1: Website builder can access Filecoin Beam UI
  • FR3.2: Account creation and authentication system
  • FR3.3: Clear instructions for DNS configuration pointing to Filecoin Beam
  • FR3.4: Real-time DNS verification status with clear success/error states
  • FR3.5: Reference implementations: Webflow, Vercel, Super

Technical Requirements

TR1: Storage & Serving

  • All dApp assets must be stored on FOC
  • Content must be retrievable via IPFS CID
  • SLA targets: <Define specific uptime, latency, and availability metrics>

TR2: Payment Tracking

  • Track storage costs per deployed dApp
  • Track egress/bandwidth costs per deployed dApp
  • Enable billing reconciliation for customers

TR3: Security

  • Verify content integrity via IPFS CID validation
  • Implement access controls for deployment credentials
  • Secure DNS record management

Out of Scope

  • Serving data from non-FOC IPFS data providers (potential future enhancement)
  • Dynamic application hosting (server-side rendering, APIs)
  • Database or backend service hosting
  • Multi-region deployment options (for initial PoC)

Open Questions & Risks

Market Validation

  • Risk: Only one customer (Aerodrome) has expressed interest
  • Action: Conduct market research to validate demand from additional customers
  • Question: What is the minimum customer commitment needed to proceed?

ENS Integration Approach

  • Decision Needed: Option 1 (universal domain support) vs Option 2 (managed TLD) vs Option 3 (DNS Link)
  • Question: What are the cost implications of purchasing and managing a new TLD for Option 2?
  • Question: Which option provides better user experience?

SLA Specifications

  • Question: What specific SLA metrics can we commit to? (uptime %, latency targets, support response times)
  • Question: What is our pricing model relative to required SLAs?

Technical Feasibility

  • Question: Can FOC consistently deliver the required SLAs?
  • Question: What is our disaster recovery and failover strategy?

Next Steps

  1. Validation: Interview 3-5 additional potential customers to validate market need
  1. Technical Spike: Prototype deployment workflow
  1. Decision: Select ENS integration approach (Option 1 vs Option 2 vs Option 3)
  1. Pricing: Define pricing model based on SLA requirements
  1. Roadmap: Create detailed implementation timeline for PoC