Product documentation
Citrix SecurSpaces™
View PDF

Set up a project for your team

August 19, 2026
Contributed by: 
T

Project Owner

You have a project and a team waiting to use it. This page takes you through preparing that project so a developer can create a workspace and start contributing, without configuring anything themselves.

Work through the steps in order. Each one builds on the last: the resources you register in steps 1 to 3 are what you package into a template in step 4, and the people you add in step 5 are the ones who use it.

Before you start

You need a project, and a role that carries the following permissions. The default Project Owner role carries all of them. A Manager carries all except Security, which is only needed for private registry credentials.

Step Permission
Review container images Resources set to Import
Add registry credentials for a private registry Security set to Manage
Import a code repository Resources set to Import
Add a secret Resources set to Manage
Create a workspace template Workspaces set to Manage Project
Add users Members set to Manage

Some of this may already be done for you. Images, repositories, and secrets can be registered at the platform or organization level, and your project inherits them. Check what you already have before adding anything.

Step 1: Review container images

A container image defines the base environment a workspace runs: the operating system, the language runtimes, and the tools your developers expect to find. Your project inherits the images registered at the platform and organization levels, so start by checking whether one of those already suits your team.

  1. Open Resources and review the container images available to the project.
  2. If an inherited image works for your team, move on to step 2.
  3. To add your own, select Add Image and provide the URL, Image Name, and Image Tag.

If the image sits in a private registry, add the registry credential first, otherwise the import cannot authenticate. Public registries need no credential.

See Container images, and Workspace images for how toolchains are layered on top of an image.

Step 2: Add a code repository

Registering a repository with the project is what allows the platform to inject credentials for it at runtime. Developers then clone and push without holding any credentials themselves, which is the main reason their device never needs Git access to your source.

Repositories are imported from a provider your platform administrator has already connected — GitHub, GitLab, Bitbucket, or Azure DevOps.

  1. Open Resources and select Import Repository.
  2. Select the provider.
  3. Select the repositories to make available in this project.

If the provider you need is not offered, it has not been connected at the platform level yet. Ask your platform administrator to add it. See Code repositories for what that involves.

See Code repositories for the project-level task.

Step 3: Configure secrets

A secret holds a password, token, or key that code needs at runtime. Registering it with the project means it is delivered to the workspace rather than kept in the repository or pasted into a developer’s shell.

Your project inherits secrets from the platform and organization levels, so review those first.

  1. Open Resources > Secrets and review what the project already has.
  2. To add one, select Add a New Secret and provide a name and value.
  3. Add a description, so the next person knows what it is for.

Secrets are attached to a workspace when the workspace is created, or through the template you build in the next step.

See Secrets.

Step 4: Create a workspace template

This is the step that turns the previous three into something a developer can use. A template combines an image, repositories, secrets, and security settings into one definition, so creating a workspace becomes a single action with a predictable result.

Without a template, every developer configures a workspace by hand, and no two are quite alike.

  1. Open Templates and select Create New Template.
  2. Choose a container image, then add the repositories, secrets, and security settings the team needs.
  3. Save it as a draft.
  4. Test the draft, then publish it as a template version.

A draft can be tested before anyone depends on it, and a published version cannot be edited afterwards, so test before you publish.

Two things worth doing here:

  • Make more than one template if your team has more than one job. Front-end and back-end developers rarely need the same tools, and a smaller image starts faster.
  • Generate a Quickstart link. It creates a workspace from the template in a single click, which is useful from a README or an engineering portal.

See Templates.

Step 5: Add users

With the environment ready, bring in the people who use it.

  1. Open People and select Add New User.
  2. Enter the user’s email address. The platform matches it against the configured identity provider.
  3. Assign a role: Guest, Developer, Manager, or Project Owner.
  4. For contractors or anyone temporary, select Set Expiration date and choose when their access ends.

Most developers should hold the Developer role, which lets them create their own workspaces from your template. Assign Guest to someone who only needs to look, and create the workspace for them yourself.

If none of the four default roles fits, you can define your own. See Roles and permissions.

See Add and remove users.

What your developers do next

Once a developer has been added and a template exists, they can create a workspace and connect to it. Point them at Your first workspace.

If you would rather send them something written for onboarding, see Onboard developers, which includes a reusable template you can adapt.

Set up a project for your team
August 19, 2026
Contributed by: 
T
August 19, 2026
Contributed by: 
T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.