Inside Tray Helix: the architecture of a governed runtime for AI-built apps

The architecture of Tray Helix, piece by piece: the governed path from a vibe-coded app to production, the managed runtime the app runs on, the credential model that keeps secrets out of code, and the five capabilities IT gets over everything that ships.

The build problem is solved. The deploy problem isn’t.

Your people already build real software with AI assistants: a ticket-routing app from Claude Code in an afternoon, an account-360 lookup in Cursor over a weekend. The build side of the lifecycle collapsed from months to days. The path to production did not.

Between a working prototype and a governed deploy sit hosting, auth, secrets handling, logging, cost metering, and an owner of record. That work has no owner. So most of these apps never ship, and the ones that do arrive ungoverned.

Builders route around the gap. Each workaround is rational in isolation. In aggregate, IT inherits a fleet of production systems it cannot enumerate.

Shadow deployments

Apps land on personal cloud accounts and forgotten VMs with no inventory entry and no owner of record. 68% of orgs that found unknown agents had believed their visibility was strong.¹

Credential sprawl

To make a prototype work, builders paste production API keys into source and config. Every pasted key is a rotation problem and a breach path. Thousands of vibe-coded apps have exposed corporate credentials on the open web, often with no authentication at all.²

No audit surface

Vibe-coded apps skip version control, deploy history, and access records. When security asks what touches customer data, the answer is email archaeology. EU AI Act high-risk obligations arrive December 2, 2027, with fines to €15M or 3% of global turnover.

Unowned AI spend

Token and compute costs land as an unattributed invoice. Retries, context expansion, and agentic loops compound out of sight. FinOps teams managing AI spend rose from 31% to 98% in two years.³

What that looks like as an object

Two products, one foundation, three layers

Tray Helix is one of two products on the Tray AI Orchestration Platform. Tray iPaaS is how teams build integrations, automations, and AI agents. Helix is how the apps people build with AI assistants get deployed, run, and governed.

They sit alongside each other, bought together or standalone, on one shared foundation. Adopting the second product adds no new governance model, credential store or access system.

Both sit on one shared foundation of four primitives:

• Repository. Everything teams build lives in one versioned repository.
• Artifacts. Builds ship as packaged, versioned artifacts.
• Credentials. One managed credential system serves both products.
• Access control. One permission model decides who can see, deploy, and use what.

Because both products share these four primitives, a governance decision made once applies to both. Connectors remain a Tray iPaaS capability; Helix connects apps to systems through managed auth.

Inside Helix: three layers

The load-bearing design decision is where governance is applied: at the deploy path, by the platform. Policy runs where the app ships.

• Surface, where people work. The builder’s AI assistant plus the helix CLI, the Helix dashboard at app.helix.tray.ai, and the App Registry where the workforce finds and launches approved apps. The builder keeps their tools, and Helix meets them at deploy time.
• Control, what IT governs. Access control, the audit record, per-app instrumentation, and AI spend visible per app. The controls attach as the app goes live, so nothing reaches production without them.
• Foundation, what Helix runs. The AI orchestration kernel: the credential broker (secrets never in code), the project service (deploy lifecycle and versioning), and the managed runtime apps execute on. These draw directly on the shared foundation above.

From helix init to a governed production deploy

The whole lifecycle runs through the helix CLI, published as @trayai/helix-cli. The builder scaffolds a project, builds it by talking to their AI assistant, and ships it with one command.

Every scaffolded project ships with an AI context layer, an MCP server, skills, and a CLAUDE.md, so the assistant writes correct Helix code from the first prompt. helix deploy returns a deployment ID you can inspect with helix deployment get.

What happens at helix deploy

Managed auth, cost metering, access scope, and the registry entry attach as the app goes live, in the same step.

Redeploys follow the same path: ship a fix with the same command, and the registry entry, auth, and cost attribution carry forward. Every version that ships is a packaged artifact, so how an app reached production is always on record.

Auth aliases: credentials the builder never sees

The most common failure mode of vibe-coded software is the pasted credential. Helix removes it structurally.

When an app needs Salesforce, Slack, Google Sheets, or another supported service, the code carries a Tray auth alias, a named reference to an authentication created in the workspace. The credential itself stays in the shared foundation. The builder never copies it, and the AI assistant never sees it, so it can’t end up in a prompt, a commit, or a config file.

• Scoped access. An app reaches only the systems it declared, and the scope is on record. Security reads the record and skips reverse-engineering the code.
• Update once, everywhere. Revoke or rotate an authentication once and it applies to every app using it. No per-app redeploys, no hunt through repos for a hardcoded copy.
• One dependency, stated plainly. Auth aliases require Tray enabled in the org, with the authentication created in Tray. It’s the same credential system your integrations already use.

“No hardcoded secrets” is true by construction for connections made through auth aliases: there’s no secret in the code, so there’s nothing to leak. The alias is also the easiest way to give an app a connection, so the secure path is the default path and a builder has nothing extra to remember.

Helix runs the app: a managed runtime IT never stands up

After the deploy, the app executes on a runtime Tray operates. It gets a URL and serves requests from the moment it ships, and a built-in database and key-value store persist data between runs, so a builder keeps state without standing up their own.

The runtime is Tray-operated and runs in US, EU and APAC regions. There is no cluster to size, no pipeline to assemble, and no VM for an app to be forgotten on. The team that built the app owns what it does, and your organization maintains no infrastructure for it.

One shape in production

Whatever the app does, IT reasons about it the same way: a versioned artifact built server-side, a named owner, connections made through managed auth, activity and logs in the dashboard, and AI spend visible per app. No snowflakes, no mystery workloads. When an app misbehaves, IT starts from one pane. Before Helix, it was five dashboards and an unowned VM.

Each app reports activity, status, errors, and health live, so an erroring app is a line in one view with a named owner next to it, and an idle app with a departed owner is visible before it becomes a liability. That’s the operational contract: IT reviews and intervenes, and Tray runs the servers.

Because every app deploys and runs through Helix, the governance surface is complete over that fleet by construction. There is no scanner guessing at what exists, and no stale inventory.

Five capabilities over everything that ships

• AI Deployment: one command to a managed runtime. One command takes an app to production and runs it. Every deploy follows the same reviewable route, so IT can reproduce exactly how an app reached production.
• App Security: SSO and managed auth, no hardcoded secrets. Every app inherits enterprise SSO and identity. Access is role-based at the org, workspace, or individual level; workspace roles are Admin, Contributor, and Read-only.
• App Registry: every app IT can see, with an owner on each. The live inventory of every app your teams ship, each with a named owner, so IT can see what exists. People self-serve the ones they’re cleared to use.
• AI Visibility: one pane, nothing hidden. Every deployed app reports its owner, workgroup, connections, activity, health, and spend, live from the first request. Filter by connection or data source to answer “what touches customer data” in minutes, and judge blast radius before deprecating an internal API.
• Cost Management: AI spend under control. LLM, token, and compute spend visible per app, so every cost has an app and an owner behind it. Billing is per workspace plus usage, never per app. The scope is AI app spend, deliberately, and general cloud FinOps sits outside it. Build-time AI stays off the meter: the assistant that writes the code runs on your own subscription.

The honest scope of visibility

Auth runs through Helix, so what each app can access, and how, is on record from the start, with nothing to reconstruct. When an auditor or the CISO asks, the answer comes from the platform record in minutes. Here’s exactly where that stops.

• Inside the line. Apps deployed through Helix: governed, visible, logged, with 30-day execution log retention.
• Outside the line. Apps deployed elsewhere. Helix isn’t a network scanner and doesn’t claim to discover them.

Helix and Tray iPaaS: two problems, one platform

The two products answer different questions. Neither replaces the other, and existing Tray iPaaS customers can adopt Helix with nothing new to stand up, because both run on the same foundation.

Most teams arrive at Helix from one side or the other: an integration problem they already know they have, or a fleet of AI-built apps they’ve just discovered. Either way it’s the same foundation underneath, and the fastest way to know whether it fits is to put one app through it.