Arcjet product philosophy: products & primitives

There’s a persistent myth that developers don’t care about security. This view tends to come from those who don’t understand a developer’s priorities or from the frustration of trying to force developers to fix security issues without context or ownership.

Developers care about security outcomes - not security tooling. They’re not shopping for WAFs or static analyzers. They’re solving real problems: bot traffic abusing a signup form, PCI audits blocking a release, or spam polluting analytics.

Security matters deeply to developers, but only as a function of how it impacts product stability, reliability, or velocity.

The Arcjet security as code SDK helps developers build security functionality directly into their apps - like a developer-first alternative to Cloudflare, but at the application layer, not the network edge. No proxies or agents - just drop it into your routes and test it locally before deploying to production.

This focus on how developers distinguish problems is fundamental to how Arcjet has been designed and packaged. We think in terms of “products” and “primitives”, where products solve specific problems using underlying primitives. 

I originally wrote this as an internal post in September 2023 as we were gearing up for our first alpha release. This framing now drives how we design APIs, docs, and onboarding: products for immediacy, primitives for extensibility. 

Products solving problems using primitives

Modern applications evolve too fast for inflexible security tools. Monolithic WAFs or ruleset configuration disconnected from the code can’t keep up with product iteration, third-party integrations, or emergent abuse vectors like AI scrapers. 

Devtools often fail in one of two ways: either they’re painful to adopt or impossible to adapt. Developers need building blocks that work out-of-the-box inside the workflow they're used to, but that can also evolve as the codebase changes. This is the graduation problem: a devtool works great on day one, but collapses under real-world complexity - forcing teams to abandon it or duct-tape around its limits.

Solving both means thinking in layers - starting with primitives, then packaging them into opinionated products.

• Primitives: Low-level, composable security functions. In Arcjet: bot protection, rate limiting, Shield WAF, email validation, and sensitive info detection.
• Products: Pre-configured bundles that solve real problems with minimal setup. Example: Signup protection, built using bot protection + rate limiting + WAF.

Think of primitives like raw AWS infrastructure - EC2, EBS, VPC. You can stitch them together to run a database across zones, or you can just use RDS, which handles it all for you. The managed service is the product; the building blocks are the primitives.

Example: Signup form protection

A developer responsible for a service that offers a free plan is seeing large spikes of fraudulent signups to their service. The signups are coming from a range of IPs and clients and are using fake or disposable email addresses. This is costing money and taking up resources.

The solution is dropping in a few lines of code, with preconfigured options ready to block the attack:

import arcjet, { protectSignup } from "@arcjet/next";
import { NextResponse } from "next/server";

const aj = arcjet({
  key: process.env.ARCJET_KEY!, // Get your site key from https://app.arcjet.com
  rules: [
    protectSignup({
      email: {
        mode: "LIVE", // will block requests. Use "DRY_RUN" to log only
        // Block emails that are disposable, invalid, or have no MX records
        block: ["DISPOSABLE", "INVALID", "NO_MX_RECORDS"],
      },
      bots: {
        mode: "LIVE",
        // configured with a list of bots to allow from
        // https://arcjet.com/bot-list
        allow: [], // "allow none" will block all detected bots
      },
      // It would be unusual for a form to be submitted more than 5 times in 10
      // minutes from the same IP address
      rateLimit: {
        // uses a sliding window rate limit
        mode: "LIVE",
        interval: "10m", // counts requests over a 10 minute sliding window
        max: 5, // allows 5 submissions within the window
      },
    }),
  ],
});

It's clear what's happening, can be tested locally, and can be adjusted based on what the developer is building. But the problem is solved quickly.

Later, the developer can swap out protectSignup() for the individual validateEmail(), detectBot(), and slidingWindow() primitives. Maybe they want to switch to a fixed window or token bucket rate limit. Perhaps they also need to include a WAF for PCI compliance. What if they want to inspect the IP metadata and flag signups coming through a VPN for manual review?

All of that is possible.

Making security solutions painless

Developers rarely browse for security tools in the abstract. They show up when something breaks - AI crawlers spike cloud bills, spam floods a trial pipeline, or login abuse leads to account takeovers.

Arcjet products are designed to solve high-friction, time-sensitive problems - fast. No tuning, no config sprawl, just results. For deeper control, security engineers or developers digging deeper can drop into the underlying primitives and extend them as needed.

Arcjet is built for developers who care about both security and shipping fast. Start with a product. Drop into the primitives when you’re ready.