Mike Cann

20 days ago

7 New Convex Components Worth Adding to Your App

The first wave of community-built Convex Components is here, and most of them solve problems agent builders run into every week, including scraping, debouncing, file storage with a CDN in front of it, email, and image generation. The Component Authoring Challenge opened up Convex Components to third-party authors for the first time, and the result is seven new primitives you can install today instead of writing the integration yourself.

This is a practitioner's tour of what shipped, who built it, and when to reach for each one. I'll walk through each component in roughly the order I'd reach for them on a real project, explain the problem it solves, and call out where it overlaps with something the Convex team already ships so you can pick without guessing.

What is a Convex Component

A Convex Component is a self-contained Convex app that lives inside your own Convex app, bringing its own database, functions, scheduler, and storage. Your app calls into the component, but the component can't call out, which is the isolation property that makes it safe to drop in without worrying about shared-database coupling or leaky abstractions.

Components can also contain other components, so hierarchies are possible. The components concept page in the Convex docs covers the full architectural model, but the short version is that a component behaves like a sandboxed mini-app you import as a dependency.

That isolation is what separates a Convex Component from a regular npm package. A package shares your database and your function namespace, whereas a component doesn't. The practical consequence is that you can install a third-party component without auditing whether it will collide with your tables, your scheduler jobs, or your action namespace. The boundary is enforced by the platform rather than by convention, which is a meaningful upgrade over the typical npm dependency story.

The other consequence worth flagging is upgrade safety. Because a component owns its own schema and migrations, upgrading the component version doesn't silently rewrite tables in your app. Which means you can pin and bump on your own schedule without coordinating a database change with the component author.

Why a Community Ecosystem Matters

Until recently, almost every Convex Component shipped from the Convex team itself, including the rate limiter, aggregates, and workpool. The Component Authoring Challenge changed that by opening the directory to outside authors and pulling in component submissions across scraping, agents, file storage, media processing, email, and payments.

This matters because reusable backend components only earn the name "ecosystem" when the platform vendor stops being the only author. A platform with a healthy component story has people outside the company packaging their integrations, which means the gaps in coverage get closed by whoever feels the pain most directly rather than by whoever has time on the core team's roadmap. The seven below are the proof point that this dynamic has started inside the Convex ecosystem.

There's a second-order effect worth naming. When community authors ship components, the quality bar for what counts as a reusable backend primitive goes up across the board, because the directory becomes a comparison surface rather than a catalog of first-party offerings. Each new submission implicitly raises the question of what a good component should expose, how it should handle errors, and how it should document its surface area.

The 7 New Convex Components

1. Firecrawl Scrape Turns Any URL Into Markdown, JSON, or Images

Firecrawl Scrape is a Convex interface to Firecrawl that takes any URL and returns HTML, Markdown, links, JSON, or images. Authored by GitMaxd, it goes beyond a thin API wrapper by adding durable caching so repeat scrapes of the same URL skip the upstream call, which saves tokens and shortens response times.

The component also exposes reactive status updates, configurable output formats, and structured JSON extraction. If you're building an agent that ingests web content, this is the shortest path from URL to usable text. The durable caching matters more than it first looks, because agent loops tend to revisit the same set of canonical URLs repeatedly during a session, and paying for that scrape once per URL rather than once per call adds up quickly.

The structured JSON extraction is the other piece worth highlighting. Pulling structured data out of a page is the kind of task that looks easy until you start handling edge cases around dynamic rendering, partial loads, and inconsistent markup, so having a component that wraps that complexity behind a stable Convex function signature is a real time saver.

2. Durable Agents Offers a Simpler Agent Primitive

Durable Agents is a community-built alternative to the official Convex Agent component, authored by Sigfried. You define an agent with its tools through a single defineAgent API that exports everything you need, and then consume the agent from the client through a React hook.

The author notes the component is still in early development, so treat it accordingly. If you want a leaner surface area than the official Agent component and you're comfortable on a moving target, it's worth a look. The appeal is that the single defineAgent entry point collapses what would otherwise be several files of glue code into one declarative definition, which is the right shape for prototyping new agent ideas where you want to keep the iteration loop tight.

The trade-off is exactly what the author warns about. Early-development components move quickly, so APIs can change between versions, and you should pin a specific version in production until the surface area stabilises. For exploratory work, the leaner API is a fair trade. For shipping agents that customers depend on today, the official Agent component is the more conservative choice.

3. Convex Debouncer Supports Sliding, Fixed, and Eager Modes

The Convex Debouncer, authored by Ilia, debounces frequent server-side work that would otherwise fire on every input event, like an expensive function reacting to a text field changing ten times per second. It supports three modes:

• Sliding: each new event resets the timer, and the function fires only after a quiet period.
• Fixed: the timer starts on the first event, and subsequent events update the arguments but don't extend the window.
• Eager: the first event fires immediately, and follow-up events queue into a single trailing call.

Pair this with client-side debouncing to save the server round-trip entirely when you can. The Debouncer sits conceptually next to the Convex rate limiter component, but it solves a different problem. Use the rate limiter when you need a hard ceiling on call frequency, and the Debouncer when you want to collapse a burst of events into one meaningful invocation.

The three-mode design is what makes this component more useful than a hand-rolled setTimeout. Sliding mode is the right default for autocomplete and search-as-you-type, because it waits for the user to stop typing. Fixed mode is the right default for write-heavy flows where you want a guaranteed cadence regardless of how long the burst lasts, so a long edit session still produces predictable backend traffic. Eager mode is the right default for user-perceived responsiveness, because the first event hits the backend immediately, so the user sees an effect, and the trailing call cleans up the final state.

Picking the wrong mode is a surprisingly common bug source, so having all three exposed as configuration rather than as separate utilities makes the component much easier to use correctly.

4. Nano Banana Wraps Google's Text-to-Image Model

Nano Banana wraps Google's Nano Banana text-to-image API, authored by Daniel Perusia. On top of the raw API, the component handles storage of generated images and surfaces real-time status updates while a generation is running.

If you're adding image generation to a product and you want the result persisted and reactive without writing the plumbing, this is the component. The real-time status piece matters because image generation latency is high enough that a synchronous request-response pattern feels broken to the user, so you want a reactive subscription that updates the UI as the generation progresses through queued, running, and complete states.

Storing the generated image inside Convex rather than handing the user a transient URL is the other detail worth calling out. Generated images are often re-displayed, re-shared, or fed back into a later generation step, so having them persisted as first-class objects in your backend, addressable by the same query patterns as the rest of your data, removes a class of bugs around expiring URLs and lost references.

5. ConvexFS Provides CDN-Backed File Storage With Transactional Guarantees

ConvexFS is a CDN-backed file storage component, authored by Jamie and built on top of bunny.net, and it closes two real gaps in Convex's built-in file storage. Files stored in S3 don't sit behind a CDN, which creates latency for globally distributed users, and the pricing of third-party CDN-backed storage can be more competitive at scale.

The more interesting feature is transactional safety. Convex mutations are transactional, but actions aren't, which means a naive integration with a third-party file service can leave you with orphaned uploads or lost references when something fails mid-flight. ConvexFS handles those transactional guarantees for you, so the file you wrote to bunny.net and the row you wrote to your database stay in sync. The actions and mutations documentation is worth reading alongside this if you want to understand why the boundary matters.

The orphaned-upload problem is the kind of bug that doesn't show up in development and shows up immediately in production, because development traffic rarely produces the partial-failure cases that trigger it. Network blips, action timeouts, and retries all create windows where the file lands on the storage provider but the database row referencing it never gets written, or the database row gets written and the upload silently fails. Handling that correctly requires either two-phase coordination or a reconciliation job, and ConvexFS encapsulates that work so you don't have to write it yourself for every project.

The CDN side is the other practical win. Latency on file delivery matters more than people expect, especially for image-heavy interfaces where every byte sits in the critical render path, so putting bunny.net's CDN in front of your assets is a measurable user-experience improvement for global audiences.

6. Transloadit Handles Media Processing for Images, Video, and Audio

Transloadit is a media processing component that uploads images, video, or audio and returns processed, delivery-ready output. Transloadit calls these workflows "assemblies," and the component wraps the Transloadit API while tracking assembly statuses on the Convex side.

Reach for this when you need transcoding, resizing, format conversion, or any media pipeline more involved than "store the file." The status tracking on the Convex side is what makes this component useful rather than a thin wrapper, because media processing is asynchronous and long-running, so you need a reactive way for the UI to follow the assembly from queued through processing to delivered.

A common shape is to pair Transloadit with ConvexFS or built-in file storage, so the original upload lands in your file storage, the assembly produces transcoded outputs, and the resulting URLs get written back into a database row that the UI subscribes to. The component handles the orchestration of that flow without forcing you to write the polling or webhook glue.

7. Loops Covers Transactional and Campaign Email

Loops, authored by Dev with Bobby, is an email-sending component that covers subscriber lists, campaigns, and transactional sends. Transactional emails are free, which makes it cleaner and cheaper than legacy email service providers for most apps.

If your app needs both marketing email and transactional email from the same primitive, Loops is the component to install. Most apps end up needing both eventually, and stitching together two providers (one for transactional, one for campaigns) is a familiar source of integration toil, because you end up reconciling subscriber lists, unsubscribe states, and template metadata across two systems that don't share a data model.

Loops collapses that into a single component, which is the right shape for the typical app where the same user is both a transactional recipient (password resets, order confirmations) and a campaign recipient (product updates, onboarding sequences). Keeping those flows in one system means an unsubscribe in one context propagates correctly to the other, which is the kind of detail that gets quietly broken in two-provider setups.

How to Add Payments to a Convex App

Four payment components are available today: Dodo, Polar, Autumn, and Stripe. Each wraps a different payment provider, and the right choice depends on the shape of your business rather than the shape of your stack.

If you're running small recurring subscriptions with light tax complexity, the Polar component handles the merchant-of-record side for you, which is a meaningful simplification because merchant-of-record providers absorb the global tax compliance work that would otherwise sit on your team. If you need fine-grained control over checkout, marketplaces, or one-time payments at scale, the Stripe component gives you the full Stripe surface area, which is the right choice when your business model demands flexibility that the merchant-of-record providers don't offer. If you want usage-based billing logic baked in, Autumn is purpose-built for that pattern and saves you from reimplementing metering, tier transitions, and overage handling on top of a generic payments API. If you want a merchant-of-record alternative with global tax handling, Dodo fits there.

Picking between four payment components is the kind of decision worth handing to an agent with your actual requirements, your geography, and your pricing model in context. The components are close enough on raw capability that the differentiator is your business shape, not the component API. If you sell to consumers in many countries, lean toward a merchant-of-record. If you sell to businesses with custom contracts, lean toward Stripe. If you sell metered access to a product, lean toward Autumn.

With four payment components available, the choice itself is now a fast decision rather than a multi-week integration project. Swapping providers used to mean rewriting webhook handlers, reconciling subscription state, and reworking your database schema. With the component model, the provider-specific work is encapsulated inside the component, so the comparison reduces to business fit rather than implementation cost.

How to Choose the Right Component for Your Job

The cleanest way to choose is by job-to-be-done rather than by component name.

If two components overlap, the deciding factor is usually whether you need the extra guarantees (transactionality in ConvexFS, durable caching in Firecrawl Scrape) or whether the lighter wrapper is enough. For prototyping, the lighter wrapper is almost always fine. For production traffic where partial failures and cost compound, the extra guarantees pay for themselves quickly.

The other heuristic worth applying is whether you expect to need the component's adjacent features within six months. If you're installing Loops only for transactional email today but you know marketing email is coming next quarter, install Loops now rather than installing a transactional-only provider and migrating later. The same logic applies to ConvexFS for file storage and Transloadit for media pipelines, because the cost of swapping a backend primitive after launch is meaningfully higher than the cost of picking the more capable component up front.

How to Submit Your Own Component to the Authoring Challenge

The Component Authoring Challenge is still accepting submissions through the Convex Components directory. The challenge no longer offers prizes, but accepted components get featured placement on the directory page where every Convex developer browses for primitives, which is the real payoff.

If you've already built an integration you keep copy-pasting between projects, that's a component candidate. The signal that an integration is ready to become a component is that you've written it more than twice, you've fixed the same bug in two different copies, and you've started to notice the shape of a reusable API forming in your head. Package it, submit it, and let the rest of the community install it instead of rebuilding it.

The other strong signal is that the integration sits at a transactional boundary your app can't easily reason about, like the file-storage-plus-database problem ConvexFS solves. Those integrations are valuable precisely because they're hard to get right, so encapsulating that work behind a stable component interface is the kind of contribution that compounds across the whole community.

When you do submit, the components that tend to land well are the ones that handle the boring parts (status tracking, retries, caching, error recovery) rather than just wrapping an upstream API. The wrapper alone is rarely worth installing as a component, because anyone can write that in an afternoon. The boring parts are where the value lives.

Frequently Asked Questions

Q: What is a Convex Component? A: A Convex Component is a self-contained Convex app that runs inside your Convex app with its own database, functions, scheduler, and storage. Your app calls into the component, but the component can't call out, which keeps it isolated from the rest of your backend.

Q: Are Convex Components isolated from the rest of my app? A: Yes. Each component has its own database, functions, scheduler, and storage, and the calling boundary is one-way, so a component can't reach back into your app's state or call your app's functions.

Q: Can a Convex Component contain other components? A: Yes. Components can contain other components, so hierarchies of reusable backend building blocks are supported.

Q: How is ConvexFS different from built-in Convex file storage? A: ConvexFS stores files on bunny.net with a CDN in front of them, offers competitive pricing for globally distributed delivery, and adds transactional guarantees for file operations performed inside Convex actions, which built-in storage doesn't handle in the same way.

Q: What's the difference between the Convex Debouncer's sliding, fixed, and eager modes? A: Sliding mode resets the timer on every new event and fires only after a quiet period. Fixed mode locks the timer to the first event and updates arguments without extending the window. Eager mode fires immediately on the first event and queues follow-up events into a single trailing call.

Q: How do I submit a component to the Convex authoring challenge? A: Submissions go through the Convex Components directory at convex.dev/components, where the challenge details and submission flow are listed.

Q: When should I pick a community component over a first-party Convex component? A: Pick the community component when it solves a problem the first-party component doesn't address, like ConvexFS's CDN delivery or Firecrawl Scrape's durable caching. Pick the first-party component when stability and long-term maintenance matter more than feature surface area, like choosing the official Agent component over Durable Agents for a production agent loop.

Q: How do I decide between the four payment components? A: Decide based on your business shape rather than the component API. Polar and Dodo are merchant-of-record providers that handle global tax compliance for you. Stripe gives you the full Stripe surface area for marketplaces and custom checkout flows. Autumn is purpose-built for usage-based billing.

Where the Convex Components Ecosystem Goes Next

Seven new components is a small number in absolute terms and a large number in trajectory terms, because every one of them was authored outside the Convex team. The directory now covers the most common jobs agent and full-stack developers run into, from scraping and image generation to file storage, media processing, email, and payments. The right move is to browse what exists before writing the integration yourself, and to submit the next component if the one you need isn't there yet.

The pattern I expect to see next is components that compose. ConvexFS plus Transloadit is already a natural pairing for a media-heavy product. Firecrawl Scrape plus an agent component is already a natural pairing for an ingestion pipeline. The first wave of community components fills the leaf-node gaps in the directory, and the second wave will probably fill the orchestration gaps between them, where a single component coordinates a multi-step flow across two or three other components.

It's hard to know which specific orchestration components will land first, because community ecosystems tend to surface their own priorities rather than the ones a platform vendor would predict. I expect the next batch to include at least one or two surprises, components that solve problems most of us hadn't thought to articulate as components yet.

Browse the full Convex component directory to see everything available today, and if you have a component idea, the authoring challenge is the fastest path to getting it in front of the entire Convex community.