Alpha release 0.2.8 · invite only

Your lakehouse.
Your perimeter.
Your intent.

blynk is a dedicated AI lakehouse platform. You describe the outcome. The agent drafts a validated plan. You approve. Governed Iceberg stays inside your stack.

Request access See the loop
stack per customer
1
plan-first writes
0%
data leaving your VPC
0

The lake product · release 0.2.8

Chat intent → validated plan → human approve → governed Iceberg

This is the appliance loop that runs inside your stack — on console.<slug>.blynk.ae. Pick an intent and watch it refuse to guess.

console · alpha.blynk.ae
autonomy: plan-first catalog lake.sales release 0.2.8

Project bound to lake.sales · federated: pg_prod, mysql_billing. Every guarded write waits for your approval. Lake Temporal runs the plan after you say yes.

Suggested intents

Guarded writes — ingest, write SQL, provisioning, drops — always stop for Approve. Reversible write_safe actions can run autonomously, journaled with a one-click undo.

Where you work

Your lake. On-premise or AWS.

Same appliance either way — your cluster, or a dedicated VPC. Analysts still land on console.<slug>.blynk.ae. No shared query engine.

console.<slug>.blynk.ae

Your lake

Trino, Polaris, Iceberg, and the plan-first console. Release 0.2.8 is the current alpha.

  1. 01
    Request

    Work email on this site. Invite only — not self-serve.

  2. 02
    Approve

    We confirm the invite and the region. Destroy always takes two people.

  3. 03
    Provision

    We install release 0.2.8 into your stack. Nothing starts without an approval.

  4. 04
    Ready

    You launch console.<slug>.blynk.ae.

Why we build blynk

Data platforms got powerful. They also got heavy.

Teams still hand-stitch catalogs, query engines, pipelines, identity and AI tooling — then hope governance holds. A shared multi-tenant engine is faster to sell and worse to isolate. Handing an LLM the keys is faster still, and far worse.

01

One stack per customer

Not a schema in a shared Trino. Isolation is the VPC or cluster, the catalog, and the identity realm.

02

Humans approve change

The agent proposes; operators decide. Approval is a product primitive, not a policy document.

03

Private by default

The model, the metadata and the bytes stay inside your perimeter. SQL never leaves blynk.

04

Open, versioned foundations

Iceberg, Polaris, Trino, SeaTunnel — fixed versions on release 0.2.8. Never :latest.

Platform · release 0.2.8

One console for the whole lakehouse

What runs on console.<slug>.blynk.ae after your stack is Ready.

Projects that remember

Durable, named chat workspaces bound to a catalog and namespace. Messages, plans, runs and decisions live together, so the "why" survives long after the query.

  • Plan versioning with edit-in-place
  • Lake Temporal deep links from every run
  • Grounded in real information_schema

Governed Iceberg

SeaTunnel writes into Apache Iceberg tables cataloged by Polaris, with per-user principals.

Federated sources

Attach Postgres, MySQL and JDBC catalogs to Trino, then plan across them in one prompt.

Local AI, no exfiltration

llama.cpp drafts plans, writes SQL and diagnoses failures — on hardware you control.

Approval as infrastructure

Every guarded mutation resolves to a plan a person signed. Reversible actions are journaled with the exact operation that undoes them.

Serve & explore

Trino Gateway routing plus Superset dashboards, wired to the same governed tables.

Architecture

Hexagonal core, versioned engines, one perimeter

The lake talks to ports. Engines are adapters — swappable, versioned, and never hardcoded into business logic. Release 0.2.8 is what we install into console.<slug>.blynk.ae.

SOURCES CONTROL PLANE EXECUTION GOVERNED LAKE Postgres · MySQL S3 · CSV · Parquet Kafka · APIs Project chat Plan (validated) Human approve llama.cpp · sqlguard · ports Temporal SeaTunnel Zeta Trino Iceberg tables Polaris catalog Superset · Gateway Keycloak OIDC · OPA per-query authorization · access mappings · audit journal

Release 0.2.8 · versioned engines

alpha · no :latest
  • blynk superset0.2.8
  • Trino479
  • SeaTunnel2.3.11
  • Polaris1.2.0
  • Temporal1.27.2
  • Keycloak26.1

Alpha

Invite only. Release 0.2.8.

Alpha is not a storefront. We provision a dedicated stack after we accept your request — AWS-hosted or on-premise.

What you get

  • Your own lake on console.<slug>.blynk.ae
  • Release 0.2.8 — the current installable alpha
  • A human approval before anything is created
  • AWS-hosted or on-premise, same product loop
Request access

Governance

The guardrails are the product

An agent that can reach production is only safe if the blast radius is defined by the platform, not by prompt discipline.

  • Write SQL is validated, not trusted. sqlguard.ValidateWrite allowlists verbs and rejects federated sinks before a plan can be approved.
  • Authorization is enforced per query. Keycloak identity resolves to engine principals and catalog grants; Trino asks OPA on every statement.
  • Tool authority is an intersection. What the agent may do = the caller's roles ∩ the project's autonomy setting. Never more.
  • Reversible writes are journaled. Each write_safe action records the operation that undoes it, so autonomy stays recoverable.

Trust

Your perimeter. AWS-hosted or on-premise.

The lake is an appliance. We install it into an isolated stack you control — a dedicated AWS account and VPC, or your own Kubernetes. Secrets never live in git. SQL never leaves blynk.

AWS-hosted

Dedicated VPC, our install

One account boundary per customer. We apply Terraform + Helm into that perimeter.

  • VPC, EKS, KMS, RDS, S3 warehouse
  • Secrets Manager → External Secrets Operator → the cluster
  • IRSA for Polaris (S3 STS) and ESO — no long-lived keys in pods

On-premise

Your cluster, same release

Same 0.2.8 appliance on hardware you already run. Overlay changes the adapters, not the product.

  • Your Kubernetes, your DNS, your CA
  • MinIO Tenant with STS instead of S3
  • CNPG / Patroni instead of RDS
  • Vault (or equivalent) → ESO → the cluster

Request access to
alpha release 0.2.8.

We provision a dedicated stack and you launch console.<slug>.blynk.ae. Invite only. No shared query engine.