the feed
The feed pipeline is open source. For every service in the catalog it tracks the vendor's official publication: the vendor's JSON endpoint or documented ranges page. Third-party aggregators are not used. Each rebuild does the following:
- Records provenance. Every service document carries the upstream URL, retrieval timestamp, and SHA-256 of the exact body it was derived from.
- Aggregates losslessly. Duplicate and subsumed ranges are removed. Adjacent exact halves are merged. The covered address set is preserved exactly, and CI verifies this on every build. Ranges are never summarized across gaps, because address space between a vendor's ranges can belong to anyone.
- Rejects suspicious data. A purpose that parses to zero ranges fails the build. A change that removes most of a service's previously published ranges is quarantined: the last-good version keeps serving until a human reviews the change.
- Publishes signed. The feed index carries an ed25519 signature, and every service document is hash-chained to the index. Verification commands are on the security page.
The output is a versioned JSON feed at feed.slash0.io/v1 with sync tokens and a changelog of every change. The Terraform provider and the hosted tier consume the same artifact. There is no separate private feed.
delivery
The hosted tier publishes each purpose as an AWS customer-managed prefix list in a
slash0-operated publisher account. There is one list per service, purpose, and
address family: egress.stripe.api.v4,
egress.datadog.agents.v6, and so on. Lists are shared to consumer
accounts through AWS RAM. Shared lists are read-only to consumers and are referenced
in security group rules the same way as AWS-managed lists.
Onboarding is one CloudFormation stack in the consumer account. It accepts the RAM
share invitation and files the rules-per-security-group quota increase the
subscriptions require. A referenced list counts its max_entries against
that quota; the stack computes the required value from the subscription set.
A reconciler compares the signed feed against every published list once per minute and converges them. slash0 has no component in the traffic path: packets flow from the consumer's security groups to the vendor directly. If slash0's systems stop, existing rules continue to work unchanged. The FAQ covers this in detail.
safeguards
The primary operational risk in a managed-list system is a bad update propagating to every consumer at once. Five independent layers can each stop one:
| layer | what it catches |
|---|---|
| 1 · feed guardrails | Truncated or malformed vendor publishes. Zero-range builds fail. Mass removals are quarantined while the last-good version keeps serving. |
| 2 · signature verification | Tampered or unsigned feed data. The reconciler verifies the ed25519 signature and hash chain before applying anything. |
| 3 · publisher guardrail | An update that would remove most of a serving list. The list is frozen and an alarm is raised, independently of layer 1. |
| 4 · canary-first rollout | A slash0-owned consumer account references every published list and takes every change first. |
| 5 · grace windows | Ranges removed by a vendor keep serving for a grace period, so old and new ranges overlap during rotations. A range the vendor re-publishes mid-grace is restored rather than removed and re-added. |
Prefix lists also version natively in AWS. Rollback is a
RestoreManagedPrefixListVersion call.
where pinning stops
IP pinning only works for services with dedicated, published ranges. The catalog
classifies every service as dedicated, mixed, or
cdn-shared. When a service is fronted by a shared CDN, pinning its
ranges would allowlist the entire CDN, including unrelated sites behind it, so the
catalog marks the service cdn-shared instead of publishing a pinnable
list. A later phase addresses these services with hostname-aware enforcement running
in the consumer's VPC, built on the same catalog.