Current limits

Policy rules name hosts, not subnets

A policy endpoint is a single IPv4 address. There is no way to write a rule covering a subnet or an address range, and there is no syntax that appears to accept one.

This is a property of the enforcement path rather than a gap in the policy language. The gateway resolves an identity by looking a packet’s address up in an exact-match table in the kernel. A prefix is not a key that table can hold, so a rule naming one cannot be compiled into anything that enforces it.

Prefix matching is planned, and it is a change to the kernel data structure the identity table uses rather than a change to the policy syntax. Rules naming single hosts will keep working unchanged when it lands.

We hold no credential of yours

Not a limit so much as a constraint worth planning around: the platform stores no cloud credential, and there is no field to paste one into. Access is a token Telaron mints, scoped to your tenant, which your cloud is configured to trust. You nominate an identity in your own project and grant it what it needs; nothing leaves your control and there is no secret of yours for us to lose.

The practical consequence is that setting up a cloud account is a configuration step on your side rather than a copy-paste of keys into ours, and that validation can only succeed once that trust is in place.

IPv4 only

Policy endpoints are IPv4 addresses. An IPv6 address is rejected at validation, for the same reason as a prefix: the identity key in the datapath is 32 bits wide.

Cloud provisioning is implemented for GCP, not for AWS

This is the largest gap on this page, and the one most likely to surprise you, so it is stated plainly — and it differs by cloud. On GCP, credential validation and region checks work end to end. Gateway instances, spoke attachment, route management and load balancers are implemented in the GCP integration but nothing in the running service invokes them yet. On AWS none of it exists; every operation is unimplemented.

Where a provider cannot do something, you get a refusal rather than a false success. Asking for a capability it does not declare returns 501 naming the provider and the capability, so the request fails where you made it instead of leaving an attachment in a pending state that nothing will ever resolve. A spoke attachment returns 501 today on both clouds, for different reasons: AWS cannot do the work, and on GCP nothing in the running service carries it out yet.

HTTP/1.1 501 Not Implemented

{"error": "capability unavailable: aws does not support spoke_attachment yet"}

HTTP/1.1 501 Not Implemented

{"error": "capability unavailable: spoke_attachment is not yet carried out by the platform on any cloud"}

Credential validation answers differently, because it is a check rather than an action: it reports the account as invalid rather than refusing outright. On GCP it is a real check — it exchanges a token, assumes the identity you nominated, and reads the project back, so a validation failure means that identity genuinely cannot see the project. On AWS it cannot yet succeed.

There is no way yet to get a gateway into your project

Gateways reach a customer’s project in two ways: Telaron provisions them into your project when you onboard, or you launch one from a cloud marketplace listing. Neither is available yet, so no path in this documentation that runs a gateway can be completed in your own cloud today. The images we build are for our own and test use and are not shared with customer projects.

A spoke cannot be registered on GCP yet

The GCP integration can build a spoke attachment, but nothing in the running service carries one out yet. Rather than record a request that would stay pending forever, the platform refuses it with 501. The peering and the steering route are yours to build until that changes.

Clusters do not reach each other

Gateways mesh with the other gateways in their own cluster and with no others. Two clusters, whether in two regions or two clouds, are not connected through the fabric. A cluster’s role is stored and does not change its behaviour. The multi-region and multi-cloud blueprints describe where this is going and are marked as not operating.

Alpha surface

• Accounts are opened on request. There is no self-serve signup yet.
• A published API reference is not part of this documentation yet. Command Center and the API cover the same surface, so Command Center is the more reliable guide to what exists today.
• The Terraform provider ships a cluster and a spoke resource and no data sources. Its reference is not published yet, and it will be generated from the provider schema rather than written by hand, so that it cannot drift from the code.
• The guided setup wizard is still being built. The steps in Getting started are the manual path it will eventually shorten.