Binari
Start a project
Binari

Binari Cloud

The control plane under our ventures.

Containers, databases, caches and access, managed in one place on Kubernetes we operate ourselves. Used by our products today. Available to teams as a private deployment.

Binari Cloud is in development. There is no self-service sign-up, published pricing or SLA yet.

What runs on it today

Kubernetes
Kubernetes environments operated by Binari, with access and workload policies scoped to each account.
PostgreSQL
Provisioned through CloudNativePG.
Valkey
Caches, created per account in a region.
Capsule
Tenancy for container workloads in fenced namespaces on BI-03.
Argo CD
GitOps delivery.
Harbor
The image registry.
Envoy Gateway and ingress-nginx
Traffic at the edge.
cert-manager
TLS certificates.
Secrets
Secret storage and access policies. Availability depends on the deployment.
Ethereum and Bitcoin RPC
RPC access is scoped per engagement. Chain readiness and access must be verified before use.

The platform

Four layers. Each one is documented, and the API enforces every rule on its own.

01 / RESOURCES

Containers, PostgreSQL and Valkey.

A resource is created in a region and owned by an account. Stop keeps the data and releases the compute. Delete asks you to type the resource name.

  • Container workloads in fenced namespaces
  • PostgreSQL through CloudNativePG
  • Valkey caches
  • Regions today: BI-03 and Binari One
Discuss your requirements

APIs and integrations

Control-plane API

One API behind the console.

Health is public. Everything else needs an authorised session or an access key tied to a service identity. Every call is checked against the identity's policies.

Both can be read in the console before sign-in.

Example · health
GET https://cloud.binari.digital/api/health

Returns the service status. No credentials required.

Product integrations

CRAYVO, LEGR, Kontact.id, ORBIT and Bridge have their own APIs and authorisation contracts. Contracts and subscriptions are not published through Binari Cloud yet. Access is scoped per engagement with the product team.

  • World Core and GISpatial search, map tiles, routing and location workflows. Access is scoped per service.Ask about access
  • TRUSSQueries, actions, policies and connectors for operational data.Ask about access
  • CommunicationsMessaging, mail and identity integrations.Ask about access
  • CRAYVOA live map of what is on in a city tonight.Ask about access
  • LEGRPersonal and business finance where every number has a source.Ask about access
  • Kontact.idA searchable map of who you know and why it matters.Ask about access
  • ORBITOnchain regulatory intelligence, run with Bridge Intelligence.Ask about access
  • BridgeA settlement network for tokenized assets, built with Bridge Intelligence.Ask about access
  • Binari AgentsAgent systems, scoped per engagement.Ask about access

Binari Nodes

Managed Ethereum and Bitcoin RPC.

Ethereum and Bitcoin RPC nodes, run on Binari Cloud and in production today.

LiveSee Binari Nodes

Private deployments

The Binari Cloud control plane on servers you own, under your name and domain. An operating agreement your team signs off. An engineering engagement, not a product you switch on.

Not every environment is a fit. If your hardware, network or compliance needs something the platform does not do yet, the assessment says so. It also says what it would take. Nothing on this page is a guarantee of SLA, certification or capacity.

01

Your identity

A branded console and domain, with the service catalogue your organisation needs.

02

Your environment

Your servers, your private Kubernetes, or a dedicated environment. We assess network, storage and capacity first.

03

Your access model

Accounts, roles and service identities mapped to your teams. Identity-provider integration is scoped in discovery.

04

Your operating agreement

Who handles upgrades, backups, incidents and support, written down before go-live. Managed by us, or handed over with documentation.

How it runs

  1. Assess

    Workloads, infrastructure, data boundaries, and the people who will use the platform.

  2. Define

    Architecture, branding, service scope, access model, responsibilities.

  3. Deploy and validate

    A pilot environment. Access, provisioning and the operational requirements in scope are tested before anyone depends on it.

  4. Operate or hand over

    Documentation, training, and an agreed support, upgrade and recovery procedure.

Talk to the engineers who run it.

Tell us what you need to run, where it should run and who operates it after launch. A senior engineer replies within one business day. Or email [email protected].

Plan a private deployment