For service providers

Sell AI to your customers
without becoming a hyperscaler.

Eldric is the multi-tenant AI infrastructure platform behind ISP, MSP, telco, and regional-cloud Private AI offerings. Your customers want AI; they do not want to send their data to OpenAI, Anthropic, Azure, or AWS. With Eldric, you run the platform on your own hardware in your own datacenters — every customer is a fully-isolated tenant, fully branded as your service, billed by you.

You keep the customer relationship. You keep the recurring revenue. You keep the data inside the jurisdiction it belongs to. The thing you do not have to build is the AI platform itself.

Service provider at the centre with four enterprise customer tenants in isolated perimeters Bank A TENANT Hospital TENANT Public sector TENANT Manufacturer TENANT YOUR BRAND ONE PLATFORM · MANY TENANTS · ONE BILL
§1 — The strategic opportunity

Three roads. One has a future.

Your enterprise customers are being asked, in board meetings, what their AI strategy is. They are answering the question one of three ways. Two of those answers leave you on the sideline — either watching the customer ship workloads to a hyperscaler, or watching them disappear into an eighteen-month internal build that may never finish. The third answer puts you at the centre of the relationship and gives you a new recurring revenue line that did not exist last year.

Why this is the moment. Enterprises are deciding their AI infrastructure now, on calendars measured in quarters. The provider that has a credible Private AI offering wins the share-of-wallet conversation. The provider that does not, watches workloads leave.

Road 1

Customer goes to a hyperscaler.

  • Their data leaves your jurisdiction.
  • Their AI bill goes to someone else.
  • The customer relationship narrows to connectivity.
  • You become a commodity transit pipe.
share of wallet shrinks

Road 2

You build your own AI stack.

  • Eighteen months minimum to a credible v1.
  • A team of platform engineers you have to hire.
  • Vendor lock-in risk to whoever you license cores from.
  • The model and tooling landscape changes under you twice a year.
time and money out of pocket

Road 3

You deploy Eldric on your own hardware.

  • Live in weeks, not quarters.
  • Multi-tenant from day one — every customer isolated.
  • White-label by default — customer never sees "Eldric".
  • Customer data stays inside your perimeter.
new recurring revenue line
Provider runs Eldric on own hardware; customers connect as branded tenants your perimeter — your hardware — your jurisdiction your datacenter Eldric — multi-tenant cluster acme corp ai.acme.example.com branded portal tenant a city bank ai.citybank.example branded portal tenant b north clinic ai.northclinic.example branded portal tenant c helio works ai.helio.example branded portal tenant d tenant connection · TLS · isolated
Fig. 01 One provider, one Eldric cluster, many isolated tenants. Each customer connects to a branded portal that lives on the provider's hardware, with their data fully siloed. The provider keeps the customer relationship; Eldric is the platform underneath.

§2 — What Eldric gives the provider

The four properties that make this a real business.

Core capabilities today

A Private-AI offering only works if the provider can confidently sell to enterprise customers who care about isolation, branding, billing, and where the bytes actually live. Eldric ships those four properties as platform primitives, not professional-services line items. The provider builds a sales motion; Eldric is what they sell.

Read this as a tooling list. Everything below is in the box. You do not pay Eldric to build the next quadrant; you configure it.
01 · isolation

Multi-tenant by design.

Every persisted artefact carries a tenant ID. The platform refuses any cross-tenant access by default; a superadmin escape hatch exists for legitimate cluster-internal calls. Per-tenant role-based access, quotas, and capability tokens — the same RBAC the provider uses for their own admins.

● available today
02 · branding

Per-tenant theming & domain.

Each tenant gets its own portal at its own subdomain, with its own colour palette, logo, typography, and copy. The chat shell, admin surfaces, and customer-facing UI all theme per tenant. The customer's users never need to know whose infrastructure is underneath.

● available today
03 · billing

Per-tenant telemetry for your invoice run.

The platform emits per-tenant usage events — requests, tokens, retrieval calls, training minutes, storage footprint — via OTLP-HTTP into whatever observability or billing stack the provider already runs. Turnkey connectors for common billing platforms ship as plugins on the roadmap; the raw signal is available today.

◐ telemetry today; turnkey billing plugins on the way
04 · sovereignty

Regional residency at the platform level.

Pin a tenant to a region. The platform refuses to replicate that tenant's data outside the regions it is allowed to live in — a rule the cluster enforces, not the operator. Federation across the provider's sites is code-complete; the customer-visible dashboard for region pinning is the final a later 5.0.x patch polish.

◐ code complete, customer dashboard in 5.0.x

§3 — What your customers get

The same AI capabilities a hyperscaler would offer.

All shipping today

If your customer is comparing your branded Private-AI offering with what they could get from a public cloud, the answer needs to be: the same capabilities, in their language, on your jurisdiction, billed in their currency. Eldric covers the long tail of what enterprises actually ask for — not just chat, but the agentic and domain-specific tooling that separates a serious offering from a demo.

White-label by default. Nothing on the customer-facing surface needs to say "Eldric". The provider owns the brand from the login screen to the support email.
Chat with their own docs RAG over private corpora Agents & tool use Matrix memory for long context Fine-tuning on their data Vision & image analysis Voice transcription & synthesis Code assistants & review Finance tooling Medical tooling Legal tooling DevOps agents Industrial protocols (OPC-UA, Modbus) Plugins for the customer's own stack

Each capability is gated by license tier — the provider chooses which capabilities to expose to which tenant, with what quota, at what price. A small-business tenant might see chat and RAG only; an enterprise tenant might get the full domain-specific catalogue plus fine-tuning. The provider sets the menu.


§4 — Deployment shape

One platform, many regions, one dashboard.

Federation code complete · dashboard later in 5.0.x

Most service providers operate across more than one site — different countries, different regulatory regions, different colocation contracts. Eldric federates across those sites without forcing one giant cluster spanning the WAN. Each region keeps its own autonomous Eldric cluster for hot paths; a federation layer keeps directory, tenant policy, and resource provisioning consistent across the whole platform. Customers see one product. Providers see one dashboard. Each region keeps the bytes that are supposed to stay there.

Why not one big cluster. Cross-continent consensus does not survive a transatlantic round trip. Federation accepts that physics and works with it — local clusters for hot paths, federated sync for tenant directory and policy.
Three-region federation — EU, US, APAC — under one provider admin provider admin console single pane of glass · all tenants · all regions federated federated region · eu Frankfurt cluster · 12 tenants region · us Ashburn cluster · 18 tenants region · apac Singapore cluster · 7 tenants federation sync · directory + policy · per-tenant residency
Fig. 02 A three-region service-provider deployment. Each region runs an autonomous Eldric cluster; the federation layer synchronises the tenant directory and policy so the provider has one console covering the whole platform. Per-tenant residency rules keep regulated data in-region. Federation is code complete; the customer-visible region-pinning dashboard ships in an upcoming 5.0.x patch.

The provider sees one platform. The customer sees their own brand. The regulator sees data that never crossed a border it was not allowed to cross.


§5 — Licensing model for providers

Resell our tiers as your SKUs.

Eldric ships with five license tiers. As a service provider, you license Eldric at the Enterprise or Custom tier and resell the capability bundle to your customers as your own SKUs, at your own retail price. Eldric does not contract with your customers; the provider keeps the relationship end to end. The map below is the menu of capability bundles you can build your SKUs from.

Wholesale pricing. Provider arrangements are negotiated — talk to us about the volume model. The point is that you set the customer-facing price, you keep the margin, and you own the renewal conversation.
Tier Scope What the bundle includes
Free 1 controller · 2 workers The trial bundle. A way to let a prospective customer experience the platform before they commit. Provider-branded; same isolation rules apply.
Standard 3 workers · RAG + agents Small-business customer. Chat, RAG over private documents, basic agents, custom models. The everyday Private-AI offering.
Professional 10 workers · multi-site · metrics Mid-market enterprise. Adds dashboard, metrics, security hardening, distributed RAG, training data generation. The "real" deployment SKU.
Enterprise 50 workers · HA · orchestration Large enterprise customer. Adds high-availability features, federation, full orchestration, AI-driven decisions, priority support. Full capability surface.
Custom unlimited · everything The provider's own license. Unlimited controllers, routers, workers across all your regions. This is what you operate the platform on.

Licenses are signed offline with Ed25519. The platform validates them locally; no phone-home, no per-token usage feed leaving your premises. The provider operates everything inside their own perimeter — the licensing is something you pay us for once a year, not a runtime dependency on something we control.


§6 — Integration

Plug into the stack you already run.

Plugin host actively expanding

Service providers do not get to throw out their existing operations stack to add a new product. Eldric is built to integrate — through a plugin host that runs server-side and client-side extensions — with what you already have: your network management system, your fleet of BMCs, your identity provider, your billing platform, your ticketing queue. The plugin host is shipping; the ecosystem of connectors is growing each release.

The plugin host is the integration surface. If a connector you need is not in the box yet, it is the same shape as the connectors that are — write it, drop it in, register it. The provider can build for their own stack without forking the platform.
NMS

Your network management system

SNMP and syslog plugins for monitoring integration with the NMS the operations team already lives in — feeding Eldric platform health into the same dashboard they watch for everything else.

BMC fleet

Your iDRAC / iLO / Redfish estate

The plugin host can run Redfish-style integrations against the bare-metal fleet — useful for AI-driven incident triage, predictive maintenance, and cluster-wide power/thermal awareness.

Identity

OIDC, SAML, LDAP

Per-tenant identity provider configuration. The customer's users authenticate against the customer's existing directory; the provider does not become an identity broker by accident.

Billing

Your existing billing platform

Per-tenant telemetry via OTLP-HTTP feeds the billing platform you already run. Turnkey connectors to common platforms (Zuora, Chargebee, custom invoice runs) ship as plugins on the roadmap; the raw signal is available today.

CRM

Your CRM & customer portal

Tenant provisioning and de-provisioning hooks. When a customer signs a contract in the provider's CRM, an Eldric tenant gets stood up; when they churn, it gets archived. The provider's portal does not need to learn a new vocabulary.

Ticketing

Your support & ticketing queue

The provider's support team gets per-tenant logs, audit trails, and usage history — surfaced through whatever ticketing system they already operate. The escalation path stays familiar.


§7 — A typical onboarding flow

From provider go-decision to customer invoice.

Six steps separate the day a provider commits to launching a Private-AI offering from the day their first customer pays an invoice for it. The platform side — steps one through three — is the part Eldric is responsible for, and the part where we work alongside the provider. The customer-facing side — steps four through six — is what the platform was built to make routine, not a bespoke integration each time.

Time-to-revenue. A provider with hardware already racked and an existing customer pipeline can reach step six in weeks, not quarters. We have seen the timeline; we can talk specifics on a call.
01

Provider deploys Eldric.

Single rack or multi-site, on the hardware the provider already operates. dnf install eldric-aios on the cluster nodes; license file activated; controller online.

02

Provider activates the bundle.

Custom-tier license issued by Eldric covers the provider's whole estate. Capability tiers configured as the provider's customer SKUs.

03

Provider wires up the stack.

Default theme, billing connector, customer-portal handoff, identity-provider hooks, support workflow. Done once; carries every future tenant.

04

Customer signs up.

Customer hits the provider's portal, picks a SKU, signs the contract. The portal calls Eldric; a new tenant is provisioned with the customer's branding and limits.

05

Customer uses the service.

The customer's users land on the provider-branded portal at the customer's own subdomain. Chat, RAG, agents, fine-tunes — whatever the SKU includes. The word "Eldric" never appears unless the provider wants it to.

06

Per-tenant telemetry → invoice.

Usage events flow through the billing connector into the provider's existing invoice run. The customer pays the provider on the provider's normal billing schedule. The recurring revenue line is open.


§8 — When this is the right fit

And when something else is.

Not every service provider should sell Private AI; not every customer base wants it. We would rather have the honest conversation up front than land a deal that does not work for either of us. Here is the cut.

Right fit for Eldric

Regional ISP
Regional ISPs with enterprise customers. You already have a B2B sales motion. Your customers are SMEs and mid-market enterprises who want sovereignty for their data and a vendor that picks up the phone in their language and time zone. Private AI rounds out the bundle.
Telco
Telcos building an AI cloud offering. You are competing with hyperscalers in your local market, and the differentiator is regulatory residency, latency, and the carrier-grade SLA you already sell. Eldric is the platform that lets you make that pitch credibly.
MSP
MSPs adding Private AI to their managed-services portfolio. You are already managing your customers' infrastructure. Adding "managed AI" to the same contract — with the same SLA, the same support team, the same monthly bill — is a natural extension. Eldric is the platform underneath.
Sovereign
Sovereign-cloud providers serving regulated industries. Banks, hospitals, governments, defence primes — customers who genuinely cannot put their workloads on a US-headquartered hyperscaler. You operate the regional cloud they trust; Eldric is the AI layer that completes it.

Probably not the right fit

Consumer
Pure consumer ISPs without B2B customers. Eldric is built for multi-tenant enterprise delivery. If you do not have an enterprise customer base today, the sales motion is the missing piece — building it is a longer project than deploying the platform.
No DC
Providers without infrastructure to host on. Eldric runs on the provider's own hardware in the provider's own datacenter. If you do not operate a datacenter, an SI partnership — where Eldric is deployed alongside a hosting partner's infrastructure — is the alternative to consider. Talk to us.
Physical AI
Use cases that require physical AI at the customer site. Robotics on a factory floor, mobile robots in a warehouse, in-vehicle AI — those are a different architecture, where compute lives on the customer's premises. See automotive.html and robotics.html for that side of the story.

Next steps

Talk to us about a partnership.

Most service-provider conversations start with a thirty-minute call: your customer base, your existing infrastructure, your timeline, your competitive landscape. We will tell you whether Eldric is the right tool for what you want to do — and if it is, what the path from today to your first paying tenant looks like.

We are a small Austrian company. The person you talk to is the person who knows the codebase. The conversation is in English or German; the licensing is signed in Vienna; the platform runs wherever you put the hardware.