Liteguard

Appearance

Workspaces, Projects, and Environments ​

Liteguard organizes your configuration across three levels: workspaces, projects, and environments. Understanding what each level does makes it easier to set up your integration and navigate the Config and Guards tabs.

Workspace ​

A workspace is the top-level organizational container. It represents your team or organization. Workspaces hold the environments that apply across all projects in that workspace, and they group related projects together.

Projects inside a workspace are independent from each other. They do not share guard configurations, rules, or rollout behavior.

In the Config tab, the workspace list is the first screen you see. Tapping or clicking a workspace in the list opens the workspace detail page, which shows the workspace's environments and its projects.

If you are on a team, everyone who shares the same Liteguard account works within the same workspace.

Project ​

A project is the application-level container. Each application you integrate with Liteguard gets its own project. A project's guards, rules, and rollout configuration are scoped to that project and do not bleed into other projects in the workspace.

A project is also the attachment point for credentials. Each project has its own Project Client Tokens and Protection Keys, both of which are found on the project detail page under Config.

When you create a workspace, you are asked to name your first project at the same time. You can add more projects later from the workspace detail page by clicking Add Project.

Environment ​

An environment is a deployment context. A single project's guards can behave differently depending on which environment the SDK is connected to. Common environment names are default, staging, and production, but you can name them anything and define as many as you need.

When you create a workspace, Liteguard creates a Default environment automatically. You can add more environments from the workspace detail page. Each environment has a name and a slug. The slug is what you pass to the SDK when initializing the client.

Guard configuration is stored per environment. When you open a guard detail page and change the default value, add a rule, or configure a rate limit, that change applies only to the environment currently shown in the context selector. Switching environments and saving again stores a separate configuration for that environment.

How these levels appear in the UI ​

The context selector is the control that tells the app which workspace, environment, and project you are viewing. It appears in the navigation area on every tab that shows project-scoped content, including Guards.

  • On mobile, the context selector appears as a bar showing the current workspace name and environment name. Tapping it opens the Switcher modal, which lists all workspaces, their environments, and their projects so you can switch between them.
  • On desktop, the context selector is in the navigation sidebar and opens the same Switcher.

The Guards tab shows only the guards for the selected project and environment. If the context selector shows a different project than you expect, use the Switcher to change it.

Where to find settings for each level ​

Workspace settings — go to Config, then tap or click the workspace. The workspace detail page shows:

  • The workspace's environments, including the option to add or edit them.
  • The workspace's projects, including the option to add new projects.

Project settings — from the workspace detail page, tap or click a project. The project detail page shows:

  • Project-level metadata.
  • The Project Client Tokens section, where you create and manage tokens for the SDK.
  • The Protection Keys section, where you manage keys used to sign protected contexts on your backend.
  • The Bundle Preview panel, which shows the assembled guard bundle that Liteguard serves to the SDK for the selected environment.

Practical example ​

Suppose you have a team called Acme that runs two applications: an API server and a mobile app. A reasonable setup would be:

  • One workspace named Acme
  • Two projects: API Server and Mobile App
  • Environments on the workspace: default, staging, production

The API Server project has its own Project Client Tokens and guard configurations. The Mobile App project has separate ones. If you add a guard to the API Server project, it does not appear in the Mobile App's guard catalog.

If you want the API Server's staging environment to serve different guard behavior than production, you configure the guard on the detail page while staging is selected in the context selector, save, then switch to production, reconfigure, and save again.