Skip to main content
Version: Weekly Build

Restricting Domain Access

Access to applications and services can be restricted at the domain or the application and service level. This guide details the methods available for limiting public access to your workloads on Codesphere.

Using Platform Built-In Restrictions​

Codesphere provides built-in platform features to control access at the infrastructure level, including resource-group-based authentication, dev domain privacy, and port-level access control.

Restrict Custom Domains to Resource Group​

The Restrict to Resource Group feature enforces authentication at the domain level. When enabled, only users who are logged into Codesphere and are members of the associated Resource Group can access the application URL.

To restrict a custom domain to resource group members:​

  1. Navigate to the Domains tab in the Resource Group Dashboard
  2. Locate the domain or subdomain to configure
  3. Click the Settings (gear icon) next to the domain
  4. Go to the Routing tab
  5. Toggle the Domain Access switch to Private
  6. Click Save changes

Domain Access Settings

How It Works

When active, all HTTP requests to the domain are intercepted. Unauthenticated visitors are redirected to the Codesphere login page. Access is granted only upon successful authentication with a valid resource group member account.

tip

Learn more about adding and configuring custom domains in the Connecting Custom Domain guide.

Restricting Dev Domains​

Dev domains are automatically generated URLs that Codesphere assigns to each workspace. These follow the format <workspace-id>.<data-center>.<your-codesphere-instance-domain> (e.g., 4220.1.codesphere.corp42.net).

To restrict access to a dev domain:​

  1. Navigate to your workspace settings
  2. Open the Edit Workspace dialog
  3. Set the workspace visibility to Private

Once private, the dev domain will only be accessible to resource group members who are signed in to their Codesphere account.

Accessing Restricted Domains​

When a domain is set to restricted (private), only members of your resource group can access the content hosted there. Users have two authentication options:

Option 1: Browser Sign-In​

Resource group members can access restricted domains by signing in to their Codesphere account in their browser. Once authenticated, they'll have access to all restricted domains associated with their resource group.

Option 2: API Key Authentication​

For programmatic access or calls to your application's API, users can authenticate using their API key.

To use API key authentication:​

Include the API key in the request header:

X-CS-Authorization: Bearer [YOUR-API-KEY]
Example using curl:​
curl -H "X-CS-Authorization: Bearer YOUR-API-KEY" https://your-restricted-domain.com
Getting Your API Key

You can generate and manage your API keys in your Codesphere user settings under the API Keys section.

Controlling which services are reachable​

Services in a Landscape are not reachable from the public internet by default. All external traffic enters the Landscape through a single entry point, the Landscape gateway. A service is only publicly reachable if it is the gateway itself, or if the Workspace Router forwards a path to it.

Services that do not require public internet access (e.g., databases, worker nodes) only declare their ports and get no path mapping on the router. They stay reachable from the other services in the same Landscape via their internal hostname: http://ws-server-<ws-id>-<service-name>.workspaces:<port>.

To change which services are publicly reachable, edit the Landscape gateway or the path mappings of the Workspace Router. See Landscape Networking for details.

Application-Level Restrictions​

For access control requirements not covered by platform settings—such as IP whitelisting or custom authentication for non-Codesphere users—restrictions must be implemented via application middleware.

Common Application-Level Patterns​

  • IP Whitelisting: Implement middleware (e.g., express-ipfilter for Node.js) to validate the X-Forwarded-For header and reject requests from unauthorized IP addresses
  • Basic Auth: Use a library (e.g., express-basic-auth for Node.js) to require a username and password defined within the application environment
  • Custom OAuth/SSO: Integrate third-party authentication providers for external user access
Granular Control

Implementing security at the code level allows for granular restrictions, such as protecting specific API routes while leaving static assets public.

Use Cases​

Access restrictions are particularly useful for:

  • Staging environments - Prevent public access to testing and QA environments
  • Internal tools - Restrict access to admin panels and internal dashboards
  • Development workspaces - Keep work-in-progress applications private
  • Database services - Use internal ports to prevent direct external access
  • Compliance requirements - Meet security policies that require access control