Private beta — onboarding data teams now

Releases

What we have shipped.

The releases that changed what you can do with NerveStax, newest first. Everything here is live for beta workspaces unless it is marked early access.

  1. Semantic layer

    LatestSemantic layerEarly access

    Data Products: one governed definition of every metric

    Define a metric once, in your dbt repository, and serve the same answer to dashboards, assistants and applications. A data product is a small set of files next to your models. NerveStax checks it against your models and tests before it is published, and applies your access rules to every query that reaches it.

    • BI tools connect over a standard PostgreSQL connection, encrypted in transit.
    • Claude can answer questions from your governed metrics through a connector your organisation approves, and you can switch it off at any time.
    • Access policies, query budgets and the audit log apply to every consumer, whether that is a dashboard, an assistant or the API.
    • Authoring in chat: the agent drafts a product from a model, checks it and previews the result before you publish. Runs on DuckDB and MotherDuck, ClickHouse and PostgreSQL.

    Ask for early access →

  2. Ingestion

    Ingestion

    SAP joins MySQL and PostgreSQL as an ingestion source

    Agents can now load SAP data over OData, the interface SAP systems publish for reporting and extraction. Behind it is a new way of adding sources: each one is a single, described module, so the next source a customer needs is a short piece of work rather than a project.

    • Four SAP authentication modes, including SAP Business One.
    • Every request stays on the SAP host you configured.
    • The same review card and pull request as every other load, so nothing installs without a person.

    The SAP integration →

  3. Security

    Security

    Single sign-on and an organisation audit log

    Connect your own identity provider and decide who signs in how. Any provider that supports OpenID Connect works, including Okta, Microsoft Entra ID, Google Workspace and Auth0. Alongside it, a new audit log records the actions people take in your organisation, with a retention policy your owners control.

    • Email-first sign-in: the email domain decides between password and single sign-on.
    • New members are created on first sign-in from your allowed domains, with the default role you choose.
    • Since 9 October the audit log covers 93 actions, from roles and secrets to schedules, backfills and ingestions.
    • Retention you set, a purge hold, a preview of what a shorter retention would delete, and exports.

    How we handle security →

  4. Ingestion

    Ingestion

    Set up an ingestion by asking for it

    Ask the agent to bring a MySQL or PostgreSQL database into the warehouse and it walks the setup with you in the conversation. It explores the source, proposes tables, keys and sync columns, and delivers the load as a pull request.

    • Credentials go through a secure form straight to encrypted storage. The model never sees them.
    • A review card lists every table with its load mode and any warnings before anything is installed.
    • A new Ingestions page shows the state, runs and history of every load, with Run now.
    • Source schema changes are detected and classified, so a new column reaches you as a decision, not a broken load.

    The MySQL integration →

  5. Scheduling

    Scheduling

    Schedules your agents understand

    Put a model on a cadence with one tag in its config. Your workspace defines the cadences it allows, each one runs in your own Airflow, and every change to a schedule arrives as a pull request.

    • A Schedules page in workspace settings to manage the cadences.
    • Each model’s cadence is shown on Data Assets, with a filter for models that are not scheduled.
    • The agent can read and check schedules and explain why a run fired. It never creates or retimes one on its own.
    • A pull request with a schedule tag that does not exist is flagged before merge.

    The Airflow integration →

  6. On-call

    On-call

    An on-call engineer for your data pipelines

    Point Airflow, dbt or any webhook at NerveStax and every alert is investigated before anyone is paged. The agent reads the logs and recent changes with read-only access, closes the noise with a written reason, and escalates real incidents with the likely cause attached.

    • Duplicate alerts are grouped, so a storm becomes one investigation.
    • Escalations are saved first, then delivered to PagerDuty, Opsgenie or Splunk On-Call.
    • If triage is unsure or fails, the alert is escalated anyway.

    Meet the on-call agent →

  7. Git

    Git

    GitLab, including self-managed

    NerveStax now works with GitLab as well as GitHub. Merge requests, checks and the PR Tests page behave the same way on both, and self-managed GitLab and GitHub Enterprise Server are supported.

    • Choose the git provider per project.
    • Agent changes arrive as merge requests your team approves, exactly as they do on GitHub.
    • Commits are authored by the person who asked for the change.

    The GitLab integration →

  8. Operations

    Operations

    Production backfills, planned with you

    Ask the agent to rebuild a model for a date range and it plans the backfill across everything downstream, asks the questions that matter, and waits for approval. Your Airflow runs the work, and a new Backfills page shows each run as it progresses.

    • The full downstream set of models is included, so nothing is left half-rebuilt.
    • Date ranges are split into chunks you can follow one by one.
    • Nothing runs without a person approving it.
  9. Deployment

    Deployment

    Self-hosted on Kubernetes, with sandboxes in your cluster

    NerveStax can now run inside your own infrastructure. A Helm chart installs the application on Kubernetes, and agent sandboxes can run as pods in your own cluster as well as on E2B’s hosted sandboxes, so code and data can stay in your network.

    • A Helm chart with production images. You bring your own PostgreSQL.
    • Choose the sandbox provider per organisation: E2B or Kubernetes.
    • Pair it with a self-hosted model for a deployment where nothing leaves your network.

    Security and deployment →

  10. Testing

    Testing

    Every pull request tested in your own Airflow

    When an agent opens a dbt pull request, your Airflow now builds and tests it before anyone reviews it, in an isolated test schema that never touches production tables. The result comes back to the pull request and to the conversation.

    • The test harness is installed into your Airflow repository through a pull request you approve.
    • Every test run is isolated from production.
    • A PR Tests page lists open pull requests and their results.

    The Airflow integration →

Private beta

Need something that is not on this list yet?

Beta teams help decide what ships next. Tell us what you run and where the time goes, and we will tell you plainly whether it is close.

→ [email protected]

Get early access →