Package and deliver a workload

Last published : Oct 22, 2026
Project Owner
Any workload that runs on Citrix SecurSpaces™, whether a development environment, an AI agent, or an application built for a business team, is delivered the same way. You package it once as a workspace template, and users or systems provision it as often as they need.
This page walks through that sequence. Each step links to the page that covers it in full.
For why one model fits every workload, see SecurSpaces as a platform for agentic workloads.
Related information
Manage
Choose how users reach a workloadCustom access items

Before you begin

You need:
  • A project to deliver the workload in. See Projects.
  • A role that can manage templates, images, and resources in that project. See Roles and permissions.
  • A platform administrator for the steps that are platform-wide: AI Gateway routing, and any network policy enforced from above the project.

1. Decide who uses it, and how

Decide first whether people or systems will use the workload, and how they reach it. That decides what the workspace must expose:
Users Usual way in
Developers The Cloud IDE, or a local IDE over SSH
Business users A custom access item that opens the application directly
Pipelines, orchestrators, or agent platforms The REST API, with workspaces created in advance
See Choose how users reach a workload.

2. Build the image

Put the software the workload needs into a container image, or layer project-specific tools onto a shared base image.

3. Give it credentials without handing them over

Prefer access the platform brokers. When a workload reaches a repository or a connected service, the SecurSpaces proxy service attaches the credential on the way out, so the workload never holds it.
Use a secret only when the workload must read the value itself. Secrets are mounted as files or environment variables, so anything running in the workspace, including an agent, can read them.

4. Limit what it can reach

Give the workload a network policy that allows only the destinations the task needs. See Assign and enforce a network policy.
This matters most for agents, which act on their own. A narrow policy limits what an agent can do with the access it has.

5. Route its AI traffic

If the workload calls AI models, have a platform administrator route that traffic through an AI Gateway. Requests are then attributed to the user, project, and workspace that made them. See AI Gateway routing.
If the workload uses MCP servers, govern that access with NetScaler® or Citrix SecurAccess ZTNA. SecurSpaces does not manage it. See Choose how users reach a workload.

6. Make it reachable

Configure the way in you chose in step 1:
  • For business users, add a custom access item that starts the application and opens its port.
  • For unattended use, create the workspaces in advance and give the orchestrator access to the REST API.

7. Capture it in a template

Bring the image, resources, policy, and access item together in a workspace template, so every workspace starts the same way.
  • Validate it by creating a workspace from the template and using it as your users will.
  • Version it. Changes go out as new template versions, and existing workspaces can be updated to them.
  • Share it. A Quickstart link creates a workspace from the template in one click.
  • Require it. To stop users creating workspaces any other way, turn on Require templates for workspace creation on their role. See Roles and permissions.

8. Organize and observe

Deliver the workload in the project of the team, or business unit, that uses it. Different teams can receive different templates and policies on the same platform. See Project and organization settings.
Once it is in use, the platform records what happens: