Choose how users reach a workload

Last published : Oct 22, 2026
Project Owner
How a workload is reached depends on who uses it. A developer works in an IDE, a business user opens an application, and a pipeline calls an API. Decide this before you build the workload, because it sets what the workspace has to expose and what goes into the template.
Related information
Package and deliver a workload

Ways in

Way in Who uses it Attended or unattended What it exposes Where it is documented
Cloud IDE Developers Attended A browser-based IDE and terminal Develop in a workspace
Local IDE over SSH Developers who keep their own editor, such as VS Code, Cursor, Windsurf, Kiro, or a JetBrains IDE Attended An SSH connection to the workspace Connect over SSH
Custom access item Business users of an agent or an application Attended One application or service, opened with one click Custom access items
Workspace App People the workspace owner shares a running application with Attended An application on a workspace port, over HTTP or HTTPS Share a running application
Graphical desktop Users of tools that need a GUI Attended A Linux desktop Run a graphical desktop
REST API Pipelines, orchestrators, and agent platforms Unattended Workspace management, for systems rather than people REST API

Choosing

  • The users are developers. Offer the Cloud IDE and SSH. Both are built in, and developers choose between them.
  • The users are not developers. Give them a custom access item that opens the application directly, so they never see an IDE. Knowledge Worker Agent is delivered this way.
  • Someone wants to show their work to others. A Workspace App shares a running application from a workspace without giving the viewers access to the workspace itself.
  • No person is involved. Unattended workloads use workspaces created in advance. A pipeline, an orchestrator, or an agent platform starts the work through the REST API, or through an orchestration layer that the agentic application provides itself. See Run AI coding agents in workspaces.
A workspace can offer more than one way in. A developer's workspace can carry an access item for an internal tool alongside the IDE, for example.

In front of the workspace: the Citrix access layer

Every way in can sit behind the wider Citrix platform. These products add controls before a user reaches the workspace:
  • Citrix Secure Access™ with Chrome Enterprise Premium applies browser and data loss policies to the session.
  • Citrix SecurAccess ZTNA, the new name for Citrix Secure Private Access™ (SPA), provides zero-trust access to private applications.
  • Citrix DaaS™ can publish an application, such as JetBrains Gateway, that connects to the workspace. See Publish JetBrains Gateway.
See Layered controls with the Citrix platform.

From the workspace outward

The ways in above are how users reach a workload. A workload also reaches out, to repositories, AI models, and enterprise services, and those connections are governed separately:
What the workload reaches How it is governed
Repositories and connected services Through the SecurSpaces proxy service, which holds the credentials and applies network policy
AI models Through AI Gateway routing, which attributes requests to the user, project, and workspace
MCP servers A workload can use Model Context Protocol (MCP) servers, but SecurSpaces does not manage access to them itself. Govern that access with NetScaler® as an MCP Gateway or with Citrix SecurAccess ZTNA.