One place to run the businesses in your care.

One product, built deep rather than wide

YekNiro is a single multi-tenant control plane, not a bundle of tools that happen to share a login. Thirteen backend services sit behind one authenticated gateway, one PostgreSQL database and one dashboard, so a customer, a ticket and an audit entry are the same objects wherever you look at them.

Polyglot where it earns its keep

TypeScript for the API and the product surfaces, Go for the queue and rule workers that have to claim work safely under concurrency, Python for the AI router and the site generator. The choice is made per service and written down, rather than applied as a house style.

We publish our own limits

Several services ship a “what is real and what is simulated” table in their README, and the project keeps a capability inventory that classifies every feature as shipped, in progress or planned. This page is written from that document. That is why some cards carry a status label instead of a superlative.

The human stays in the loop where an agent acts

Where an agent acts on your business, approval is not a policy we promise to follow: a database trigger refuses any non-read-only agent action until a human approval has been recorded, and re-checks it at execution. Two things sit outside that boundary and we would rather name them here. Support auto-reply is yours to set — leave its mode on “automatic” and AI-drafted replies go to your customers with nobody approving them, which is why it defaults to approval-required and why the setting says so on the screen that holds it. And the self-healing service acts on a timer inside limits granted up front, not per incident.

Gateway

The single front door. Issues a short-lived token on email, password and organisation identifier; resolves the tenant from the verified token claim and overwrites any identity headers a client tried to supply; enforces a read/write permission split per route group; rate-limits per tenant; and writes an audit row for every mutating request.

Core API

The domain service: customers, websites, tickets, conversations, SLA policies, billing, marketplace, payouts, notifications, reports, settings, API keys, users, roles and invitations. It is the only writer of the conversation log.

AI Router

Owns the decision pipeline and the per-tenant AI budget. One interface in front of Anthropic, Google Gemini, Cohere and any endpoint speaking the OpenAI wire protocol — including a model you run yourself. Enabling a provider is a configuration edit.

Rule Engine

Evaluates a JSON condition language against an incoming event and returns the action to take with no model call at all. Every change snapshots an immutable version, and a rollback restores an earlier version as a new one rather than erasing history.

Automation Engine

A worker pool that claims queued jobs safely across replicas, holds a lease while it works, and sweeps up anything a crashed worker abandoned. What each job type really does is documented job by job, including the ones that stop short.

Security

Dependency scanning against the live OSV.dev database, regex secret scanning with real line numbers and masked output, a heuristic content scan, and generation of a least-privilege Kubernetes isolation policy. A separate privileged binary runs untrusted build steps under kernel-enforced namespaces and cgroups.

GitHub Integration

Connects customer repositories as untrusted, has them scanned before they may deploy, verifies GitHub webhook signatures and queues deployments. It never executes deployment code itself — that separation is the point.

Event Ingestion

Batched event intake in front of ClickHouse, with a durable on-disk spool that keeps accepting writes when ClickHouse is unavailable and evicts oldest-first past a size cap.

Messaging

Inbound and outbound over shared provider adapters. Outbound takes an existing message row and delivers it with retries, backoff and a terminal dead-letter state. Inbound verifies the provider's signature, writes a durable inbox, and relays each message onward.

OpenClaw

The control plane for agents that act on the platform. Agents are per-tenant rows with their own enable flag; registration grants nothing; a tool must be granted explicitly; anything not read-only needs a recorded approval; runs hold recoverable leases and everything lands in an append-only log.

Healer

Runs health probes on an interval, recovers only what is safe to recover — a stalled job requeued, a stuck job failed, a stale run lease released — and escalates everything else to a person. It holds no shell, no Docker socket and no SSH key; every action available to it is a database update.

Recommendations

Answers “what should I do next?” from data the platform already holds. Deterministic rules rather than a model: every score is arithmetic over rows, and every recommendation is an action rather than an observation.

Website Builder

Turns a business brief into a complete, validated static site. It works with no AI credentials at all — the AI path substitutes the copy, not the structure — and a queue worker drives each generation to a terminal state.

The operator dashboard

Thirty-six screens grouped as Operate, Intelligence, Commerce and Admin: the daily queue of websites, customers, tickets, conversations, deliveries and automation jobs, plus the analysis, commerce and administration surfaces around them.

The gateway API

Everything the dashboard does, it does through the same authenticated API you can call yourself. Tenant API keys are created and revoked from a screen, and each route group states which permission it requires for reads and which for writes.

The website generator

A brief in, a complete validated static site out, reviewable artifact by artifact before you publish it. Provider, model, prompt identifier and a content fingerprint are recorded per artifact, so you can always tell what wrote a page.

Builds and validates — publishing to a host is not built yet

The agent control plane

Register an agent, verify its environment, grant it named tools, enable it — each a separate act — then read every run, every proposed action and every approval in one append-only log.

The AI budget manager

One screen that holds the monthly token quota, the cloud spend cap and the cloud kill switch for a tenant, with a per-request ledger recording exact token counts, cost and latency behind it.

The answer cache

Browse and search everything the platform has already worked out for this tenant. A repeat question is matched against it and answered without calling a model, and the entry records how often it has been reused.

Billing, marketplace and payouts

Plans, subscriptions and invoices; marketplace listings and purchases; a seller earnings ledger that database triggers refuse to update or delete; and payout runs with an idempotency key so a crash cannot pay twice.

Stripe integration built in — supply your key to enable checkout and payouts

The support desk

Ticket queue and detail with notes, events and escalation; the conversation log behind each ticket; SLA policies driving every deadline; and a per-customer communication profile with a governance list of things it is forbidden to infer.

A cost-ordered pipeline, not a chatbot

Automation, then rules, then the answer cache, then a local model, then a cloud model. The automation and rule layers are deterministic Go services that never call a model, and the cache answers outright when it is confident enough. The expensive layer is the last resort rather than the default.

Local-first, with named exceptions

Most questions try a model you host yourself before any cloud provider is considered. A short list named in the code — business strategy, legal and advanced finance — goes straight to a cloud model, because correctness outranks cost in those domains and deciding that up front is better than guessing case by case.

Your provider, your key

Anthropic, Google Gemini, Cohere and any OpenAI-compatible endpoint, including self-hosted ones, sit behind a single interface with a documented per-domain preference order and a cheapest-enabled fallback. No provider is configured for you, and none is required to stand the platform up.

It learns from the answers it has already given

A resolved question is embedded and stored, and the next question close enough to it is answered from that entry with no model call. This is a cache of the platform's own answers — not a search over documents you upload, which is deliberately not a customer feature here.

The agent kinds that ship

An operations assistant, a site-triage agent and a support-triage agent. Each is a per-tenant row with its own enable flag and its own environment verification, so enabling one for a customer says nothing about any other.

Scheduled analysis produces a finding

An agent run loads its subscription, puts the question through the pipeline and records a real run with its result. It stops there by design: the finding is the deliverable, and acting on it is a separate decision a person makes.

In progress — runs are triggered by hand; no scheduler is deployed yet

Drafted support replies, held for approval

The router drafts a reply, the core service stores it in a queue, and it is not sent until a person approves it. The draft route is reachable only from inside that workflow, so a draft cannot be obtained without the record of it existing.

In progress — the API is live, the review screen is not built yet

The agent catalogue

Browse the agent types available to a tenant, the subscriptions in place and the history of every run, from a screen in the dashboard.

Read-only today — subscriptions are set up for you, not from the screen

We do not dress up a confidence score

No provider returns a real confidence for free-form text. What the platform records is a heuristic, and it is used internally to decide whether to escalate a local answer to the cloud — not offered to you as a measure of how right an answer is.

Prompt injection is mitigated, not solved

Untrusted text never occupies the instruction position and each rendering carries its own fence marker. The module that does this calls itself a mitigation rather than a boundary, and so do we.

Object storage for backups (S3 or MinIO)

The one integration proven end to end: a dump written to a bucket, the host destroyed, and the database restored from the bucket alone with every row accounted for.

Signature verification for Stripe, GitHub and Meta

Every inbound webhook is authenticated by verifying a signature over the raw request body. The verifiers are tested with deliberately forged payloads and deliberately broken implementations, and every one of them is refused.

Telegram

Two-way. Inbound authentication is verified end to end here, and every wrong credential is refused. Outbound messages are constructed and issued for real; that path is proven up to the network boundary, since this build environment cannot reach Telegram.

Inbound verified here; outbound proven up to the network boundary

WhatsApp Business Cloud

Inbound webhooks are signature-verified and land in the same durable inbox as Telegram. Outbound is built and issues real requests. Message templates are not implemented, so a free-form reply sent outside the window WhatsApp allows will dead-letter with Meta's own error recorded against it.

In progress — templates for replies outside the allowed window are not built

GitHub App

Repositories are connected as untrusted and stay that way until scanned; “could not verify” never becomes “verified”, and a deployment is refused outright unless the repository is verified. Webhook deliveries are signature-checked and recorded.

Built and reaching GitHub — register your app and supply its key

Stripe

Checkout sessions, invoices, subscriptions, payout transfers and multi-secret webhook rotation are all implemented and reviewable. Without your key the checkout route answers with a plain service-unavailable rather than pretending, and no card has ever been charged through this code.

Built in — supply your key to enable it

AI providers

Anthropic, Google Gemini, Cohere and a long list of backends speaking the OpenAI wire protocol — hosted services and models you run yourself alike. None is configured out of the box; without a key the pipeline records that no provider was available rather than inventing an answer.

Bring your own key — nothing is pre-configured

OSV.dev vulnerability data

Dependency scans query the live OSV.dev database. There is no bundled copy and no offline fallback, which means the scanner needs to reach the internet and says so rather than reporting a clean result it did not earn.

Requires network access to OSV.dev — an unreachable scan never counts as verified

Email (Resend)

Transactional email is wired through Resend. One caveat we would rather state than let you discover: without a key the send reports that nothing was sent, and the operation that requested it still succeeds — so email is not the channel to rely on for anything that must not be missed.

In progress — sending fails open, so treat delivery as unconfirmed

ClickHouse for event analytics

Events are batched into ClickHouse behind a durable spool, under a versioned schema applied by a migrator that refuses a file changed after it was applied. It was chosen for high-volume event workloads, and it runs in the full deployment profile.

Prometheus metrics

Every service exposes a metrics endpoint, so the platform can be scraped by the monitoring stack you already run rather than requiring one of ours.

Event intake that survives an outage

Events are batched into ClickHouse, and when ClickHouse is unavailable they go to a durable on-disk spool that keeps accepting writes and evicts oldest-first once it hits its size cap. The intake path does not fail because the warehouse is down.

Event summaries

Business and product events, aggregated by day and by type, on a screen in the dashboard.

Needs the full deployment profile, which is where ClickHouse runs

Period reports

Real aggregate counts over automation jobs, rule executions, AI requests and security events, written to a report you can open later. The generator is real and produces the report whenever it is triggered.

In progress — reports are generated on request; there is no schedule and no mailout yet

Deployment and downtime monitoring

Deployment status alongside recorded downtime events, so what changed and what broke are on the same screen rather than in two systems.

The business-intelligence advisor

Read the generated reports, then ask a question about them in plain language. The question goes through the same cost-ordered pipeline as everything else, which means it can be answered from the cache without a model at all.

A ledger for every AI request

Exact token counts, cost, recorded latency and which layer resolved it, per request. Budget usage is incremented atomically rather than read-then-written, so requests running at the same time cannot undercount each other.

Reuse you can see

Each cached answer records how often it has been reused, so the value of the cheapest layer is visible on the screen rather than asserted on a marketing page.

Row-level security is the tenant boundary

Every service sets the acting tenant on the connection before it queries anything, and PostgreSQL policies do the rest. A bug in application code still cannot return another tenant's data, and a connection that never set a tenant sees nothing at all rather than erroring — it fails closed.

The application role cannot step around it

Services connect as a role holding neither superuser nor bypass rights, because PostgreSQL skips policies entirely for a bypassing role. Policies are forced even for the tables' owner, and cross-tenant background work uses a separate, narrowly granted role whose every use writes an audit row.

A whole class of hole closed permanently

A set of views once read their base tables as their owner, which meant policies were never consulted — a total cross-tenant read. A guard now fails the migration if any view over a tenant-scoped table is created without invoker rights, so the mistake cannot be reintroduced by someone who has not heard the story.

Identity never comes from the client

The gateway resolves the tenant from a verified token claim and overwrites the tenant, user and service headers on every proxied request, after the header spread — so a client cannot supply any of them. Forwarding headers are replaced rather than appended, because appending preserves an attacker-controlled entry a downstream service would read as the caller.

Services do not trust network position

Every proxied request carries a signed credential with the target service's name inside the signature, so a credential minted for one service cannot be replayed against another. Every service behind the gateway verifies it.

Roles with a read/write split

Owner, developer, analyst and viewer, against a permission catalogue where reading and writing are gated separately per route group. A queue worker can read the SLA policy it is measured against without being able to rewrite it.

Append-only ledgers

Audit entries, security events, the agent activity log and the seller earnings ledger all carry triggers that refuse updates and deletes. The only sanctioned deletion path is tenant erasure, which must write its receipt first.

A login that tells you nothing it should not

Every failure path records a distinct reason on the server while returning one generic message to the client, and an attempted email that matched nothing is never stored. Someone probing for valid accounts learns the same thing from every attempt.

The approval gate is re-checked at execution

An action is proposed in milliseconds and executed once a human has been found — minutes or days later, by which time a tool grant may have been revoked or the agent disabled. The database re-checks the boundary at the moment of execution, and gaps of exactly that shape were demonstrated against a real database before each became a refusal.

Dependency and secret scanning

Dependency scanning against the live OSV.dev database, plus regex secret scanning with real line numbers and masked output. The content heuristic alongside them is a handful of text patterns and one level of decoding — it is labelled a heuristic in every response and will miss most real malware, which is why we do not call it antivirus.

The malware check is a heuristic, not antivirus

Untrusted build steps run in a kernel-enforced sandbox

Namespaces and cgroups, proven by tests that execute genuinely hostile build steps and watch them fail. The ceiling is stated rather than hidden: namespaces share the host kernel, and a stronger isolation layer is proposed rather than built.

The security screen

The security event log, filterable by type, severity and status, is a screen. Starting a scan is an API call today — the screen shows findings, it does not launch scans.

In progress — findings have a screen, running a scan does not

Running many businesses without running many logins

Every customer, website, ticket and invoice you are responsible for sits in one account, kept apart by the database rather than by which browser profile you happened to open. Team members get roles rather than shared credentials.

Keeping a support queue inside its deadlines

Ticket deadlines are computed from SLA policies rather than typed into a spreadsheet, a breached filter shows you what has already slipped, and the recommendation engine tells you which ticket to open next and why.

Using AI without an unpredictable bill

Most questions never reach a paid model: automation, rules and the answer cache take them first. What does reach one is bounded by a token quota and a cloud spend cap per customer, with a kill switch when you want the answer to come from a model you host instead.

Not paying twice for the same answer

A resolved question is stored and matched against the next one close enough to it. The second time a problem appears, the answer is instant and free, and you can see how often each entry has been reused.

Getting a new business a site to review

A brief becomes a complete, validated static site — pages, styling, artwork and metadata — that you review artifact by artifact before anything is published. It works even before any AI provider is configured.

Answering customers where they already are

Telegram and WhatsApp messages arrive in a durable inbox and become part of the same conversation log your tickets link to. Replies go out through a queue that retries, backs off, and shows you exactly what failed instead of losing it.

Being able to say who did what

Every state-changing request writes an audit entry at the gateway, independently of the service that handled it, and those rows cannot be updated or deleted. Every agent action carries the approval that permitted it and the person who gave it.

Knowing what is in the code you are about to deploy

A connected repository is untrusted until scanned, deployment is refused unless verification actually succeeded, and dependency findings land in a security log you can work through by severity.

Digital agencies and web studios

Client sites, client support and client billing under one account, with per-client isolation enforced by the database and per-client AI budgets so one demanding account cannot spend another's allowance.

Managed service providers

Health probes, automation jobs, dependency scanning and a security log across every account you look after, with escalation to a person for anything that cannot be safely handled automatically.

Groups running several brands

Each brand is a tenant with its own websites, customers, conversations and reports, while roles decide who at the centre can see across them and who cannot.

Franchise and multi-branch operators

One operating model applied across locations: the same SLA policies, the same automation rules, the same messaging channels, with per-location records that stay separated in the database.

Resellers and marketplace operators

Listings, purchases, a seller earnings ledger that cannot be edited after the fact, payout runs with an idempotency key, and plan limits enforced in the schema rather than in a policy document.

In-house operations teams

The same control plane pointed at your own properties, with the API and tenant API keys available so the platform can be driven from the tooling you already have.

How a request gets answered

Each layer hands on only what it cannot resolve, so the expensive one is the last resort rather than the default — and whatever answered is written back for next time.

One front door

The gateway is the only internet-reachable component. It authenticates, resolves the tenant, enforces permissions, rate-limits and audits before any service behind it sees the request — and the services refuse anything that did not arrive with its signed credential.

One database, with the boundary inside it

Seventy-four tables under one PostgreSQL instance, with row-level security policies enforcing tenant scope and forced even for the tables' owner. Composite foreign keys mean a child row cannot point at another tenant's parent.

A warehouse for events, separate from the operational store

ClickHouse holds the event stream under a versioned schema, so analytical queries never contend with the transactional database that customer records live in.

Languages chosen per service, not by house style

TypeScript for API and product services, Go for the concurrent queue and rule workers, Python for the AI router and the site generator. Each choice is recorded with its reason rather than assumed.

A dashboard that is one application

Thirty-six screens in Next.js, fully bilingual with right-to-left layout, built on a token-driven design system without a CSS framework or a component library bolted on.

Observability without a bundled stack

Every service exposes Prometheus metrics and a health endpoint, and the healer's probes run against them. You point your existing monitoring at it rather than adopting ours.

Tests that fail loudly when they stop running

TypeScript, Go, Python and shell integration suites, plus guards that assert how many tests actually executed — because a suite that silently stops running reports the same green as one that passed.

The stated scope limit

Multi-region and high availability are explicitly outside this iteration. We would rather name that here than let an architecture diagram imply it.

Not in this iteration — single region, no high-availability story yet