Deployment

One binary, one configuration in Git, all your topologies.

The same binary and the same signed image, from a laptop to a cluster: the configuration lives in Git, is validated offline and reloads without losing a request. Here is the shared cycle, then each topology with its status at the published release.

What makes it strong to operate

One binary, one signed image, one chart
The same thing from a laptop (docker run) to a VM (systemd) and a cluster (Helm); archive and image verifiable with cosign.
Git, the only source
Contract and flexway.yaml versioned, validated offline; the console proposes as pull requests, it never writes.
Reloaded without loss
No restart, no request lost; an invalid configuration is refused as a whole, the running one keeps serving.
Refuse rather than fall
In-flight ceiling, sheddable traffic shed first, draining on stop; each replica tells the console its state.

The GitOps configuration cycle

Shared by every topology: nothing reaches the gateway without review, the console never writes to production.

flexwayAPI, AI and agent gateway

The configuration cycle: the contract and flexway.yaml in Git; flexway validate offline in your CI; deployment of the same signed image, by chart or by file; hot reload without losing a request, an invalid configuration is refused as a whole and the running one keeps serving; the console observes; a change goes back as a proposal, a diff in a pull request, never a write.

Git repository: The Git repository: the contract and flexway.yaml under version control, the configuration's only source of truth.
Your CI: Your CI runs flexway validate offline: an operation without an upstream or a policy that does not compile fails the CI.
Deployment: The deployment: the same signed image, by Helm chart, container or binary, from the laptop to the cluster.
Reload: The hot reload: the new configuration is served without a restart; if invalid, it is refused and the previous one keeps serving.
Console: The console observes: version served, last reload, traffic and health of each replica; it does not write.
Proposal: The proposal: a change prepared in the console becomes a checked diff, opened as a pull request.

Traffic

The topologies

When to use it, what scales and how, what to operate, the status in the catalogue of the published release. No throughput or latency figure: no benchmark is published.

One binary, one containerKubernetes, high availabilitySeveral environmentsBehind a meshSovereign, no egressSeveral gatewaysPlannedEdgePlanned in 1.11

flexwayAPI, AI and agent gateway

One binary or one container: callers call a single Flexway process, which reads a flexway.yaml file and its contract and relays to your upstreams. SIGHUP reloads the configuration, SIGTERM drains.

Callers: The callers (applications, partners, agents): they see one address only, Flexway's.
flexway: A single Flexway process: it reads its file, decides and relays; SIGHUP reloads, SIGTERM drains.
flexway.yaml: The flexway.yaml file and its contract: validated offline, reloaded without a restart.
Upstreams: Your upstreams (services, models): they receive only the requests Flexway let through.

Traffic
Configuration and observation
Perimeter

Status: Delivered · v0.1.0
When to use it: A trial (docker run), a VM or bare metal: the binary is the service, under systemd or any supervisor.
What scales: The machine. One replica, its counters in memory; for several instances, the Kubernetes topology or a Redis-compatible shared cache.
What to operate: A flexway.yaml file and its contract; the signed archive verified with cosign; SIGHUP reloads, SIGTERM drains.

flexwayAPI, AI and agent gateway

Kubernetes in high availability: callers go through your edge (ingress, load balancer), which spreads them over three stateless Flexway replicas. Each replica decides alone and reconciles with the Redis-compatible shared cache (Redis, Dragonfly or Valkey). The contract and the configuration, versioned in Git, are a ConfigMap: a helm upgrade is served without restart. The console follows the health of each replica.

Callers: The callers (applications, partners, agents): they see one address only, Flexway's.
Edge: Your edge (ingress, load balancer): it spreads load across the replicas and can terminate mTLS.
flexway · replica 1: A stateless Flexway replica: it decides on its own; add more to scale out, SIGTERM drains it.
flexway · replica 2: A stateless Flexway replica: it decides on its own; add more to scale out, SIGTERM drains it.
flexway · replica 3: A stateless Flexway replica: it decides on its own; add more to scale out, SIGTERM drains it.
Upstreams: Your upstreams (services, models): they receive only the requests Flexway let through.
ConfigMap: The ConfigMap: the contract and flexway.yaml mounted as a directory; a helm upgrade is served without a restart.
Git repository: The Git repository: the versioned configuration, applied by your deployment tool.
Counter cache: An optional Redis-compatible shared cache: the replicas reconcile their counters through it at regular intervals, with no round trip on the path.
Console: The console: health of each replica, dashboards and alerts.

Traffic
Configuration and observation
Shared counter cache
Perimeter

Status: Delivered · v1.4.0
When to use it: Production in a cluster: several stateless replicas behind your edge (ingress, load balancer).
What scales: Add replicas. Each replica decides alone and reconciles with the Redis-compatible shared cache (Redis, Dragonfly or Valkey): no round trip on the path. Without a shared cache, counters are local to each replica.
What to operate: helm install; the contract and configuration in a ConfigMap, a helm upgrade is served without restart; the Secrets the chart does not create; the counter cache; monitoring.enabled installs a dashboard and alerts.

flexwayAPI, AI and agent gateway

Several environments: a Git repository holds one configuration per environment; dev, staging and prod run the same signed Flexway image; a configuration validated in dev is promoted to staging then prod by pull request; the console of each environment observes and proposes as pull requests.

Git repository: The Git repository: one shared contract, each environment's values by reference, never in clear.
Dev · flexway: The development environment: the same signed image as production, only the values change.
Staging · flexway: Pre-production: the same image, promoted by a reviewed, traced pull request.
Prod · flexway: Production: the same image, promoted by a reviewed, traced pull request.
Console: The console: it proposes changes as pull requests, promotion goes through Git.

Traffic
Configuration and observation
Perimeter

Status: Delivered · v1.2.0Delivered by its building blocks: same image, ${VAR} and file: references, offline validation, proposals as pull requests.
When to use it: Separate dev, staging and prod, with a reviewed and traced promotion.
What scales: Each environment by its topology (binary or Kubernetes); only the values change, never the binary.
What to operate: One configuration per environment in Git, secrets by reference; flexway validate in the CI of each branch or folder.
Note: Flexway's guide does not describe this path end to end yet: this topology assembles delivered features, each one documented.

flexwayAPI, AI and agent gateway

In front of a service mesh: callers go through the mesh proxy, which checks the peer's mTLS identity and spreads over the Flexway replicas; Flexway reads that identity from a trusted header and relays to the mesh's services. Encryption and routing between services stay with the mesh.

Callers: The mesh's other services: their mTLS identity is checked by the proxy before reaching Flexway.
Mesh proxy: The service mesh proxy: it checks the peer's mTLS identity and spreads load across the replicas.
flexway · replica 1: A Flexway replica behind the mesh proxy: it reads the identity the proxy has checked.
flexway · replica 2: A Flexway replica behind the mesh proxy: it reads the identity the proxy has checked.
Services: Your services: they receive only the requests Flexway let through.

Traffic
Perimeter

Status: Delivered · v0.1.0
When to use it: A cluster with a service mesh: Flexway fits into it instead of replacing it.
What scales: The replicas, spread by the mesh, which sees the replicas.
What to operate: server.trusted_proxies: [local] and server.peer_identity_header (for example l5d-client-id); encryption and routing between services stay with the mesh.

flexwayAPI, AI and agent gateway

Sovereign, no network egress: internal callers, Flexway, the Git repository, observability, internal models and services all run on your infrastructure; no connector tied to a cloud provider; the configuration is validated offline. A licence checked without a network call is coming.

Internal callers: Your internal callers, inside your network: nothing transits through an outside service.
flexway: Flexway in your infrastructure: signed image, with no database and no outside service on the path.
Git repository: Your Git repository, on your premises: the configuration is validated offline there.
Observability: Your OpenTelemetry observability, on your premises: traces and metrics do not leave your infrastructure.
Internal models: Your internal models: a request marked sensitive is pinned to them.
Services: Your services: they receive only the requests Flexway let through.
Licence: Planned: Flexway's licence, verified offline, without calling a publisher service.

Traffic
Configuration and observation
Perimeter
Planned

Status: Delivered · v0.1.0Delivered, except the licence checked offline, coming with no release.
When to use it: Regulated sectors, closed networks: everything must run on your infrastructure.
What scales: As its base topology (binary or Kubernetes).
What to operate: Everything in-house: Git repository, OpenTelemetry observability, models; no connector tied to a cloud provider; flexway validate offline.

flexwayAPI, AI and agent gateway

Several gateways, one console: a shared console would follow several gateways, with declared scopes (gateways, metrics source, repository). Coming, with no release in the catalogue: fully dashed.

Metrics source: Planned: A metrics source per scope, for the shared console.
Shared console: Planned: A console shared by a whole fleet of gateways, with declared scopes.
Repository: Planned: One configuration repository per scope.
Gateway A: Planned: A Flexway gateway of the fleet, followed from the shared console.
Gateway B: Planned: A Flexway gateway of the fleet, followed from the shared console.
Gateway C: Planned: A Flexway gateway of the fleet, followed from the shared console.

Configuration and observation
Planned

Status: Planned
When to use it: A fleet of gateways followed from a single console.
What scales: -
What to operate: Today, one console per gateway.

flexwayAPI, AI and agent gateway

Edge: the same binary on each site (plant, farm), the signed configuration pulled and checked by the site, local decisions without network, buffering left to the local broker. Planned, fully dashed.

Signed configuration: Planned in 1.11: A signed configuration, which each site pulls and verifies itself.
Site 1 · flexway: Planned in 1.11: Flexway on a site: it decides locally, without a central plane, with a signed configuration.
Site 2 · flexway: Planned in 1.11: Flexway on a site: it decides locally, without a central plane, with a signed configuration.
Local broker: Planned in 1.11: A broker local to the site, which buffers when the network is missing.
Local broker: Planned in 1.11: A broker local to the site, which buffers when the network is missing.

Traffic
Planned

Status: Planned in 1.11
When to use it: Sites (plant, farm) that must decide without network.
What scales: One gateway per site.
What to operate: Signed configuration pulled by the site; buffering stays with the local broker.

Let's talk about your gateway

Flexwiz is a young company: you talk directly with the person who founds it. Tell us what you want to run through Flexway. We talk about your infrastructure and your digital sovereignty requirements.

Talk to an expert Write to Flexwiz

Online booking is coming soon; until then, an e-mail is enough.

One binary, one configuration in Git, all your topologies.

What makes it strong to operate

One binary, one signed image, one chart

Git, the only source

Reloaded without loss

Refuse rather than fall

The GitOps configuration cycle

The topologies

One binary or one container

Kubernetes, high availability

Several environments

In front of a service mesh

Sovereign, no network egress

Several gateways, one console

Edge: one gateway per site

Let's talk about your gateway