Every project runs isolated from the rest of your organisation. Network policies are how you open exactly the connections you intend — link two projects, allow outbound traffic to a payment provider, restrict a database to the one app that uses it — and nothing more. Reusable, attachable, and declarative.
Projects can't reach each other by default, and your workloads can't be reached from projects you didn't authorise. A network policy is a set of explicit allow rules layered on top of that baseline — you describe what should be permitted, and everything else stays closed.
Control who can reach a workload and which networks it can reach out to — by IP range and port (Layer 3/4), or by domain name at the application layer (L7). Mix and match in a single policy; a policy with only IP and port rules never touches the application layer.
What a policy controls
A network policy is a small, readable set of rules. Each rule describes a connection you want to allow — inbound from another project, or outbound to a network you trust.
Ingress
Name the other projects in your organisation that are allowed to reach the workloads this policy protects. Link a frontend project to its backend, or an internal tools project to a shared service, without opening either to the world.
Egress
List the IP ranges your workloads are allowed to send traffic to. Adding any range switches outbound traffic to deny-by-default — only the ranges you approve get through, while name resolution keeps working.
Application layer
Restrict outbound connections to a named set of domains — api.stripe.com, your data warehouse, an approved partner API — instead of a block of IP addresses that can drift. This is application-layer (L7) control, evaluated by the domain the request is actually going to.
Ports
Narrow any rule to specific ports and protocols (TCP or UDP). Allow a peer project to reach only your API port, or an outbound range only on 443. Leave ports off to allow them all.
Reusable
Policies live at the organisation level. Write a “web tier” or “payments egress” policy once and attach it wherever it belongs — one project, several projects, or a single container. Change it in one place and every attachment follows.
Layered
Rules only ever addpermitted connections on top of the private baseline. There is no way for a policy to silently widen access you didn't ask for — if it isn't written down, it isn't allowed.
Scope
The same policy can guard an entire project or a single workload. You choose the blast radius at attach time — and you’re billed for what you attach.
Attach a policy to a project and it applies to every container and datastore in it. Ideal for organisation-wide guardrails — “this project may only talk to these two others” — that should hold no matter what gets deployed later.
Attach a policy to one container to give just that workload its own outbound allowances or ingress peers, without changing the rest of the project. Perfect for the one service that needs to reach an external API.
Scope a policy to a managed datastore to control precisely which workloads may connect to it. Application-layer domain rules don't apply to datastores — only the IP, port, and peer rules that gate who can reach them.
Common workflows
The same building blocks — peers, egress ranges, egress domains, ports — cover a lot of ground. A few patterns we see most.
Keep two projects private from everything else, but let the frontend reach the backend's API port. One policy, one peer, one port — and no other project can get in.
A workload that handles payments should only ever reach your provider. Restrict its outbound traffic to a short list of domains so a compromised dependency can't exfiltrate data to anywhere else.
Scope a policy to your managed datastore so only the application that owns it can connect. Other projects — and other workloads in the same project — are refused at the network.
Attach an “approved egress” policy to a whole project so every current and future workload inherits the same outbound allow-list. New deployments are constrained the moment they land.
Create a policy, then attach it to a project, container, or datastore from a guided panel. Application-layer rules surface their per-replica cost before you commit.
Full lifecycle through Reis (`reis network_policy:create`, `reis project:attach`) or the `bahriya_network_policy` Terraform resource. The same rules, as code.
One organisation-level inventory shows every policy, what it allows, and where it is attached. Create, attach, and detach actions are written to the activity log.
A small per-policy base rate, plus a per-region rate while a policy is attached to a project. Application-layer (L7) domain rules add a per-replica charge only on the containers they apply to.
Coming Soon
Planned for later in 2026/2027, timeline subject to change.
Redis-compatible in-memory data store with persistent snapshots and restore. Session caching, queues, pub/sub, and real-time data — without Redis licensing concerns.
Managed relational database with automated backups, point-in-time recovery, and regional deployment. A production-ready RDBMS for structured data and transactional workloads.
Managed PostgreSQL with automated backups, point-in-time recovery, and regional deployment. Advanced SQL features, JSONB support, and extensions for modern application workloads.
A globally distributed, multi-region document database with built-in replication. Conflict-free sync across regions for offline-first applications and geo-distributed NoSQL workloads.
S3-compatible object storage for files, media, backups, and static assets. Accessible from your containers or directly via standard S3 APIs and client libraries.
Global content delivery network for static assets, media, and API acceleration. Edge caching across multiple PoPs with automatic origin pull from your containers or object storage.
Your own dedicated API gateway in front of your services. JWT/OAuth2/OIDC and key auth, fine-grained rate limiting and quotas, request/response transformations, circuit breakers, canary releases and traffic splitting, gRPC and WebSocket proxying, and rich per-route analytics — all configured declaratively via Reis or the Console.
Managed RabbitMQ for asynchronous messaging between containers. Multi-region clusters, project-private networking, and per-node billing — same operational model as Memcached.
Start private, open exactly what you need, and keep the rest shut — across every project and region.
