Deploy to an Environment
This page takes the finished package to a running application on the C3 Agentic AI Platform. You deploy to a single-node environment from the C3 AI VS Code extension to see real data, or you promote to a shared environment through C3 Studio for a production deployment. When you finish, the application is live at https://<cluster>/<env>/<app>/, where the c3auth cookie authenticates every call and you handle no token yourself.
Before you begin
Have the bundle built into ui/content and spaMode configured, from Bundle and Serve. A single-node deploy runs from the C3 AI VS Code extension and needs no administrator role in Studio. A shared-environment deploy runs through C3 Studio, so sign in to Studio interactively before you start it.
Choose the environment type first, because the deploy path differs. A single-node environment (SNE) deploys from the C3 AI VS Code extension, which connects only to single-node environments. A shared environment is the production target, and its deploy goes through C3 Studio and Release Management, because the extension cannot reach it.
Deploy to a single-node environment
Run the application with a real backend by deploying it to the single-node environment the extension connects to. You start the application from the extension, then open it from Studio.
Step 1: Start the application from the extension
Open Start Application in the C3 AI VS Code extension. Set Root package to your package, leave Application name at its default, and choose an Application mode. Development keeps the source code and metadata writeable with test data available, which suits iteration, and Test makes them read-only. Select Submit.
The extension provisions the package, registers the Types, loads the seed data, and starts the application. Wait for it to finish connecting and starting.
End state: the extension reports the application started on the single-node environment.
Step 2: Open the application from Studio
Sign in to Studio, open the Apps page, find the application, and open its details. Select the Open application icon in the application header. The application loads at its address, such as https://<cluster>/<env>/<app>/, and serves real data. The browser sends the c3auth cookie with every call, so no token handling is needed.
End state: the application runs on the single-node environment at its address, serving real data.
Deploy to a shared environment
Promote the application to a shared environment for a production deployment. You create the environment, push the package to a GitHub repository, build a versioned artifact in Release Management, and deploy that artifact through the Studio wizard. The extension is not involved, because it connects only to single-node environments.
Step 1: Create the shared environment
In Studio, select the Envs tab and select New Environment. In the Create New Environment wizard, select Shared Environment in the Environment Type step, then complete the remaining steps and submit. Wait for the environment to reach Running, because a stopped environment disables the deploy sources.
End state: a shared environment shows Running in the Studio Envs tab.
Step 2: Push the package to a GitHub repository
Put the package in a GitHub repository, because Release Management builds the artifact from a repository branch rather than from your local files. Create a repository, commit the package with its built ui/content, and push the branch. Note the repository URL, the branch name, and a repository authentication token, because the next step needs all three.
End state: the package is on a branch in a GitHub repository.
Step 3: Build a versioned artifact
Build a versioned artifact from the package, so the deploy references a specific, immutable version that captures the committed ui/content. In Studio, open Releases, select the Branches tab, and select New branch configuration. Set the source control to GitHub, the HTTPS repository URL to the package's repository, a repository authentication token, and a branch regular expression that matches the branch. Scope the branch configuration's packages path to the package's parent folder, so the build validates only that package. Save it, open the Build Queue tab, and start a build for the branch. When the build finishes, the artifact appears under the Artifacts tab.
To set up your package so the platform build compiles, tests, and packages its UI, see UI Package Structure for npm Applications.
End state: a named artifact version of the package exists in Release Management.
Step 4: Create and deploy the application
Create the application from the artifact through the Studio deployment wizard, which has four phases: Select Package, Configure Deployment, Configure Compute, and Review. Select Create Application on the running shared environment to open the wizard.
In Select Package, confirm the Environment is your shared environment, set Source from to Built Artifacts, and set the package name and the version you built. Select Next.
In Configure Deployment, enter an Application name, and set Application mode to Production for a shared deployment, or Test for validation. Select Next.
In Configure Compute, choose a shared-environment sizing. Small suits getting started, Medium and Large add task nodes for heavier workloads, and Custom sets the nodes yourself. Select Next.
In Review, confirm the selections and start the application. The environment provisions the package, loads the seed data, and serves ui/content natively at the application address.
End state: the application shows a Running status on the shared environment.
Use Built Artifacts when GitHub Repository and Synced Development Packages are greyed out, which is common. The GitHub Repository source needs a GitHub integration configured for the environment, and Synced Development Packages needs a package first synced through the C3 AI VS Code extension. A stopped environment disables all four sources, so confirm the environment is running first.
Confirm the application loads
Open https://<cluster>/<env>/<app>/ and confirm the single-page application loads at the root and that a path route resolves, rather than redirecting to the console. The application is served on the environment's own origin, so the c3auth cookie authenticates every call with no token handling.
End state: the application is reachable and serves at its URL.
By default the local preview from npm run dev serves the interface only, with no backend. It runs on your machine, where no C3 backend answers api/8, so the data calls return 404 and the list stays empty. The served application with real data comes from Start Application on a single-node environment, or from Built Artifacts on a shared environment, not from the default local preview.
Iterate
To ship a change to a shared environment, rebuild the bundle, version a new artifact, and redeploy, which repeats the shared-environment steps. On a single-node environment, run Start Application again from the extension. On an environment that hibernates to save resources, resume the environment first and then the application, because resuming the application while the environment is down fails.
End state: a change is live through a new artifact version or a fresh Start Application.
What you have now
You have the application live at its URL, either on a single-node environment from the extension or on a shared environment from a Built Artifacts deploy, and a repeatable path to ship changes. The guide is complete: the application is built, served, and deployed.
Decisions on this page
The environment type and the application mode are the two choices.
| Decision | Options | Recommendation |
|---|---|---|
| Environment | a single-node environment from the C3 AI VS Code extension, or a shared environment through a Built Artifacts deploy | A shared environment through Built Artifacts for production; a single-node environment for iteration |
| Application mode | Production or Test | Production for a shared deployment; Test when you need to debug |