Dive deep into the architecture of Tray Helix: 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 gap
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 belongs to no one. So most of these apps never ship, and the ones that do arrive ungoverned.
AI builds ever reach production and deliver real value
Tray analysis · MIT NANDA + S&P Global
of orgs found unknown AI agents running
Cloud Security Alliance, 2026
of organizations breached in their AI apps had no AI access controls
IBM, Cost of a Data Breach, 2025
of FinOps teams now manage AI spend
FinOps Foundation, 2026
Builders route around the gap. Each workaround is rational in isolation. In aggregate, IT inherits a fleet of production systems it cannot enumerate.
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
Cloud Security Alliance, 2026
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
Wired, cited via Gartner G00858202, June 2026
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
Token and compute costs land as an unattributed invoice. Retries, context expansion, and agentic loops compound quietly.
FinOps teams managing AI spend rose from 31% to 98% in two years
FinOps Foundation, 2026
Same builder, same tools, same app. The only thing Helix changes is the path between the prototype and production, which is where every governance control attaches.
Establish paved roads by applying platform engineering principles and do not provide direct access to vibe coding tools or AI coding agents. Expose the access through a self-service platform that enforces governance, security, and usage controls by design.
The map
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 means no new governance model, no new credential store, and no new access system.
Integration, automation, and AI agents built as one platform. Its scale is platform scale: the shared foundation already moves 1T+ processes a year at 100% execution uptime.
Deployment, runtime, and governance for AI-built apps. Builders keep Claude Code, Codex, Cursor, GitHub Copilot, Windsurf, or any MCP-compatible assistant.
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.
The load-bearing design decision is where governance is applied: at the deploy path, by the platform, rather than by a ticket queue. Policy runs where the app ships.
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. Nothing here replaces the builder's tools, Helix meets them at deploy time.
Access control, optional approval gates, the audit record, per-app instrumentation, and cost governance. Approval is applied where risk warrants it: an internal lookup tool flows straight through, while an app touching customer data waits for sign-off.
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.
Nothing technically stops a builder from using a personal cloud account. The design bet is adoption economics: one command to production beats an evening of DIY infrastructure, so the paved road wins by default.
The path
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.
$ npm install -g @trayai/helix-cli # requires Node ≥ 24.18.0
$ helix login # opens the browser, finishes on approval
$ helix init campaign-reporter # scaffold the project
$ cd campaign-reporter && npm install
$ helix dev # local server, file-system routing, hot reload
# build by talking to your AI assistant, e.g. Claude Code:
# "Create a marketing campaign reporter app"
$ helix auth connect salesforce # wire a workspace credential to an alias
$ helix deploy # upload source, provision, go live
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.
helix deploy Governance is not a separate step. Managed auth, cost metering, access scope, and the registry entry attach as the app goes live.
Source is uploaded and packaged server-side into a versioned artifact in the foundation repository. The project is provisioned on the first deploy. No local build to reproduce, no snowflake environments.
Connections resolve to Tray auth aliases. No raw credential enters the artifact, the code, or the builder's machine, and the app's reach is limited to the systems it declared.
The runtime meters what the app consumes and attributes it to the app and the team that caused it, from the first run.
A title and description are auto-generated; the owner, workgroup, and connections are recorded. The app is discoverable by the people cleared to use it.
Activity, logs, and metrics are on from the first request, so the app is monitored the moment it goes live.
The app lands on the managed runtime and gets a URL. It appears in the dashboard with logs, activity, and spend.
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.
The guarantee
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 cannot end up in a prompt, a commit, or a config file.
salesforce-prod. No secret present. An app reaches only the systems it declared, and the scope is on record. Security reads the record instead of reverse-engineering code.
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.
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 is no secret in the code, so there is nothing to leak. The alias is also the easiest way to give an app a connection, so the secure path is the default path, not an extra step a builder has to remember.
Steady state
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 key-value store persists data between runs, so a builder keeps state without standing up a database.
The runtime is Tray-operated and runs in a USA region today. 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; nobody in your organization maintains infrastructure for it.
The same app, after one command. Every row that was missing on the laptop is now a fact the platform holds, not because someone filed a ticket, but because governance state travels with the app.
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 metered against a budget. No snowflakes, no mystery workloads. When an app misbehaves, IT starts from one pane instead of 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 is the operational contract: IT reviews and intervenes; it does not babysit 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.
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, and gate the risky ones without slowing the rest.
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.
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 are cleared to use.
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.
LLM, token, and compute spend attributed to the app and the team that caused it, with budgets and limits that stop a runaway loop before the invoice lands. Scoped to AI app spend, deliberately, not general cloud FinOps. Build-time AI stays off the meter: the assistant that writes the code runs on your own subscription.
Auth runs through Helix, so what each app can access, and how, is recorded rather than reconstructed. When an auditor or the CISO asks, the answer comes from the platform record in minutes. Here is exactly where that stops.
Apps deployed through Helix: governed, visible, logged, with 30-day execution log retention.
Apps deployed elsewhere. Helix is not a network scanner and does not claim to discover them.
Where it fits
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.
See how IT keeps control while your teams build with the AI tools they already use.
Your private status link is on its way to your inbox.