What Is Rollup-as-a-Service (RaaS)? Explained

Rollup-as-a-Service (RaaS) refers to companies that operate and maintain Layer 2 rollup infrastructure on behalf of clients, letting a team launch and run a custom chain without hiring the specialized engineers needed to manage sequencers, provers, and node infrastructure directly.

RaaS is best understood as the rollup equivalent of managed cloud hosting: just as most companies don't run their own data centers today, a growing share of teams launching app-specific chains don't want to become distributed-systems infrastructure operators either. Providers like Caldera and Conduit sit in that gap.

What a RaaS provider actually does

Launching and operating a rollup involves ongoing responsibilities beyond the initial deployment: running sequencer nodes reliably, monitoring for downtime, managing upgrades to the underlying rollup framework (OP Stack, Arbitrum Orbit, Polygon CDK, and others), handling data-availability configuration, and providing block explorers, RPC endpoints, and bridge UIs that end users actually interact with.

A RaaS provider typically packages all of this into a managed offering: a client picks their desired framework, data-availability approach, and configuration options, and the provider handles deployment, uptime, and ongoing operational maintenance — usually for a recurring fee or a share of sequencer revenue, rather than requiring the client to build an in-house infrastructure team.

Why teams choose RaaS over building it themselves

• Speed to launch. Going from decision to a live testnet or mainnet chain can take days to weeks rather than months, because the operational tooling already exists.
• Lower fixed cost. No need to hire a dedicated infrastructure and reliability team before you know whether the chain will attract enough usage to justify it.
• Framework flexibility. Reputable providers typically support multiple underlying stacks, letting a client pick optimistic or zk-rollup tooling, or switch approaches, without switching vendors entirely.
• Focus on the application. Teams building a specific app (a game, an exchange, a specific DeFi protocol) often want to spend engineering time on the application itself, not on rollup plumbing.

The trade-offs worth understanding

Outsourcing infrastructure operation introduces a dependency. If a RaaS provider experiences downtime, gets acquired, changes pricing, or discontinues support, a client chain's operational continuity is affected in ways a fully in-house team could respond to more directly. This doesn't necessarily affect the chain's underlying security model (which is generally determined by the rollup framework and data-availability choice, not the operator), but it does affect uptime and support reliability — worth diligring before committing a serious application to any specific provider.

It's also worth being clear-eyed that RaaS doesn't change the fundamental trust and decentralization questions any new rollup faces: who controls the sequencer, what happens if it goes down, and how withdrawals are secured are all still determined by the underlying rollup architecture — see our broader piece on launching your own L2 rollup for those considerations, and our explainer on how L2s inherit Ethereum's security for what that architecture actually guarantees.

Approach	Time to launch	Ongoing operational burden	Best fit
Build in-house	Months+	High — dedicated team needed	Large teams, long-term strategic chains
Rollup-as-a-Service	Days to weeks	Low — outsourced to provider	Apps testing product-market fit, smaller teams

Who RaaS is for

RaaS makes the most sense for teams that have identified a genuine reason to want a dedicated chain — high transaction volume from a single application, need for custom gas tokens or permissioning, or a desire to capture sequencer revenue — but don't have (or don't want to build) in-house rollup operations expertise. It's less suited to teams that haven't yet validated whether their application needs a dedicated chain at all; building on an existing general-purpose L2 or L1 first, and only migrating to a dedicated rollup once usage justifies it, is often the more capital-efficient path.

Evaluating a RaaS provider

Questions worth asking before committing: What rollup frameworks do they support, and can you migrate between them later? What's their track record on uptime for existing client chains? How is sequencer revenue split? What happens to your chain's continuity if you end the relationship — do you retain the ability to run your own sequencer, or does the provider hold operational keys you can't easily replace? These questions matter more than marketing claims about speed or cost, since they determine how much real control and continuity your project retains.

Bottom line

Rollup-as-a-Service lowers the barrier to launching a custom Layer 2 by outsourcing the operational burden of running sequencers, provers, and supporting infrastructure — but it doesn't change the underlying security and decentralization trade-offs of the rollup framework itself, and it does introduce a dependency on the provider's own reliability. Treat the choice of RaaS provider as a serious vendor-selection decision, not just a technical configuration step, especially for any chain expected to hold meaningful value.