Confidential

About the project

What Catalyst is, where the name comes from, and who's behind it.

CCG Catalyst turns the GAI lab at Cybercore into self-service compute. Engineers, customers, and partners log in, pick the machine they need, and have a working environment in minutes, with GPUs when the work calls for it. Access is scoped to each person, usage is metered, and every action is logged to CMMC standards.

Neuroscale AI is designing and building Catalyst on behalf of GAI. It runs on hardware GAI already owns, so customer data and workloads stay on-prem in the lab cage.

The name

Entity

CCG

Computacenter Government. GAI becomes CCG in January 2027, so the platform carries the new name from the start.

Platform

Catalyst

A catalyst speeds up a reaction without getting used up. The platform does the same for AI work: it gets a project from idea to working demo faster, then resets for the next customer.

Write it as CCG Catalyst in formal documents. Catalyst on its own is fine in everyday use.

What it's for

Customer experimentation

Customers get their own sandboxes to test AI software against mission problems and run proofs of concept.

Vendor demos

The team stands up partner software in ready-made environments, shows it, and resets it after each session.

Internal development

CCG engineers get AI-ready machines for daily development and production work, with coding agents installed.

Who's involved

Neuroscale AI

Designs and builds the platform.

GAI

Owns and operates Catalyst. Becomes CCG in January 2027.

Computacenter

Parent company of GAI.

Cybercore

The data center that houses the lab cage and all Catalyst hardware.

Who uses it

Four groups share the platform. Each one sees a different part of it, set by their role.

Customers

Scoped access to their own sandboxes for experimentation, testing, and proofs of concept.

Gen AI outcome engineers

Build demos and proofs of concept for customer mission areas.

Internal developers

AI-enabled sandboxes for development and production work.

Platform admins

Manage hosts, capacity, quotas, security, and usage reporting.

Sandboxes

A sandbox is an isolated machine with its own CPU, memory, disk, and optionally GPUs. It can be a container or a full virtual machine.

Figure 1. What's inside a sandbox, how people reach it, and the platform services around it.

Lifecycle

Create

From a sandbox type, a saved image, or a template.

Start, stop, pause, resume

Standard controls from the UI, API, or CLI.

Fork

Copy a running or stopped sandbox into a new one with the same state.

Recover

Deleted sandboxes can be brought back within a set retention window.

Delete permanently

Removes the sandbox and wipes its storage.

Auto-stop

Shuts down after a set time or once the machine goes idle.

Extend

Push back the stop time from the UI or the API.

Scheduled start and stop Proposed

Bring demo machines up before a customer meeting and shut them down after.

Figure 2. How a sandbox moves between states. Purged is the only one that can't be undone.

Sandbox types

Instance types

Choose CPU, memory, disk, GPU model, and GPU count.

Preset sizes

CPU small, medium, and large. Fractional GPU, 1 GPU, 8 GPU, and multi-node.

Fractional GPUs

Split a GPU with NVIDIA MIG or time-slicing for lighter work.

Containers or VMs

Containers start in seconds. Full VMs cover desktops, Windows, and anything that needs stronger isolation.

ARM64

Supported on the Grace Hopper and GB10 systems.

Access

Browser desktop

Secure VNC desktop in the browser. Nothing to install.

SSH

Direct SSH through a single gateway, so sandboxes don't need their own public IPs.

SSH keys

Users add and manage their own keys.

Port exposure

Publish any port to a private link, for example 8080-sbx-4f2a.catalyst.ccg.com

Port forwarding

For non-web traffic, through the CLI.

Persistent connections

Links and tunnels stay up across restarts.

One surface

Every action in the UI is also available in the API and CLI.

Figure 3. How a request reaches a sandbox. Every sandbox shares the same small set of public IPs, so nothing is exposed directly.

Visibility and control

Command history

Every command run in a sandbox is recorded and kept with the audit log.

Exec API

Run commands inside a sandbox from code.

Files API

Read, write, upload, and download files in a sandbox.

Metrics

CPU, memory, disk, I/O, and network, plus GPU utilization, memory, temperature, and power. Live and historical.

Logs and events

A timeline of everything that happened to each sandbox.

Snapshots and images

Two ways to save a sandbox, depending on how long you need to keep it.

	SnapshotShort term	ImageLong term
What it is	A point-in-time save of a sandbox	A named, saved snapshot
Kept for	A few days, then removed automatically	Until someone deletes it
Naming	Timestamped	Named and versioned
Used to	Pick up the same sandbox where it left off	Start new sandboxes, or resume one
Shared with	The sandbox owner	Private, team, organization, or everyone

Promote

Turn any snapshot into an image in one click.

Fast starts

New sandboxes clone at the storage layer instead of copying whole disks.

Image library

Versions, descriptions, and sharing at the private, team, organization, or global level.

Base images

Hardened Ubuntu and RHEL, CUDA and PyTorch, NVIDIA NIM, and Windows.

Environments and secrets

How credentials and settings get into a sandbox without anyone pasting keys by hand.

Figure 4. Settings from the organization, project, and user merge into one named environment. When a sandbox starts, variables and secrets are injected, and every secret read is logged.

Environments

Sets of variables, credentials, and secrets that are injected when a sandbox starts.

Secret handling

Encrypted at rest, hidden after saving, and every read is logged.

Scopes

Organization, project, and user level.

Credential profiles

Named bundles of API keys and tokens you attach to a sandbox or agent.

Catalyst API keys

Scoped keys so code inside a sandbox can call Catalyst with only the permissions it needs.

AI agents

Coding agents come installed and signed in with each person's own plan, without exposing their keys.

Figure 5. Admins switch each coding agent on or off per organization to meet supply chain requirements. A lead agent can split a task across a swarm of sub-agents, each working in its own forked sandbox, then merge the results.

Preloaded tools

Claude Code and Codex installed and ready on agent sandboxes.

Credential proxy

Claude Code and Codex subscriptions or API keys reach the sandbox through a proxy, so raw keys never sit on the machine.

Agent profiles

Each person's or team's plan and keys follow them into any sandbox.

Agent controls

Admins turn each agent on or off per organization, so customers only get vendors and models that pass their supply chain review. Versions can be pinned.

Sub-agent swarms

A lead agent can split a task across many sub-agents, each in its own forked sandbox, then bring the results back together. Swarm size counts against the same quotas.

Usage tracking

Agent usage by user, team, and customer.

On-prem model gateway Proposed

Sandboxes call open models running on lab GPUs, so sensitive data stays inside the cage.

Templates and demos

Repeatable environments the team can launch for a customer in one click and reset afterward.

Figure 6. A demo template opens a full desktop in the customer's browser. Here, Kamiwaza and EdgeRunner AI run side by side on a GPU-backed Catalyst sandbox, and the desktop resets to its image after the session.

Templates

One-click environments with one or more sandboxes plus their networking, storage, and secrets.

Vendor demo catalog

Ready-made demo environments for partner software.

Customer demo links Proposed

Time-boxed, scoped access to a demo for a specific customer.

Demo reset Proposed

Put a demo back to its image after each session.

Access and permissions

Who can see and do what. Customers and internal teams share the platform but never see each other's resources.

Tenancy

Organization, then project, then sandbox. An organization is a customer or an internal group.

Isolation

Customers see only their own resources. Enforced in identity, networking, and storage.

Roles

Platform admin, org admin, engineer, customer user, viewer, and auditor.

Permissions

Fine-grained control over create, connect, fork, delete, port exposure, and GPU use.

Single sign-on

SAML or OIDC with Entra ID or Okta. MFA required.

CAC and PIV Proposed

Smart card login.

Just-in-time access Proposed

Privileged actions need approval and expire on their own.

Metering and quotas

Every hour of compute is counted, so capacity is shared fairly and can be reported by customer.

Figure 7. On the left, each group's GPU hours against its monthly quota, with an alert before the limit. On the right, GPUs booked ahead for demos, so the hardware is free when the customer arrives.

Metering

GPU hours, CPU hours, memory GB hours, storage GB months, and network.

Quotas

Per organization, project, or user, by day, month, or a custom period.

Concurrency limits

Cap how many GPUs or sandboxes can run at once.

Allocation

Set aside capacity for a customer, team, or program.

GPU reservations Proposed

Book a DGX or a GPU pool for a set window ahead of a demo or proof of concept.

Budget alerts

Warnings as limits approach, and an automatic stop when they're reached.

Reports

Usage and showback by customer, team, and project. Exportable.

Infrastructure and hosts

New servers join the platform by installing an agent. From there, Catalyst knows what the host has and can start placing work on it.

Host onboarding

Install the Catalyst agent on a new server and register it.

Inventory

CPU, memory, GPU model and count, MIG support, NICs, InfiniBand, and storage, collected automatically.

Runtime checks

Drivers, CUDA, container runtime, and firmware are validated before a host takes work.

Resource pools

Group hosts into pools such as H200, general GPU, CPU and VM, and ARM.

Health

Host and GPU health through NVIDIA DCGM.

Maintenance mode

Drain sandboxes off a host before servicing it.

Out-of-band control

Power, health, and firmware through iDRAC and iLO over Redfish.

Growth

More XE7740s, DGX and H100 systems, and Intel Gaudi can be added the same way.

Storage

PowerStore, PowerScale, and Unity back sandbox disks, datasets, model weights, and snapshots.

Shared datasets Proposed

Mount datasets and model weights read-only into many sandboxes at once.

Networking

The lab has only a handful of public IPs. This is how every sandbox stays reachable anyway.

Shared front door

One to five public IPs serve every sandbox through a reverse proxy and SSH gateway, with wildcard DNS and TLS on *.catalyst.ccg.com

No per-sandbox public IPs

All traffic goes through the front door.

Tenant networks

Each organization is isolated by default. No cross-tenant traffic.

Egress control

Allow or block outbound internet per organization or sandbox, including fully air-gapped.

InfiniBand

High-speed fabric for multi-node GPU jobs.

Security and CMMC

Built for CMMC Level 2 from the start, covering the 110 controls in NIST SP 800-171 and the handling of Controlled Unclassified Information.

CMMCLevel 2

Frameworks Catalyst is built to align with

CMMC 2.0 Level 2Primary target

NIST SP 800-171110 controls for CUI

SOC 2 Type IISecurity and availability

ISO/IEC 27001Security management

FIPS 140-3Validated encryption

DISA STIGsHardened base images

These are design targets. Formal certification or attestation follows an independent assessment.

Encryption

FIPS 140 validated, in transit and at rest.

Audit log

Logins, sandbox actions, secret reads, and admin changes. Tamper-evident and exportable to a SIEM.

Session recording Proposed

SSH and desktop sessions recorded for review.

Hardened images

STIG-hardened base images and regular vulnerability scans of images and hosts.

Account controls

Least privilege by default, session timeouts, and lockout.

Data disposal

Storage is wiped on delete. Retention is configurable.

Backup and recovery

For the control plane and the image library.

API, CLI, and integrations

Everything in the UI can also be scripted, so teams can automate demos and connect Catalyst to their own tools.

Figure 8. The Catalyst stack, from the clients people use down to the lab hardware. Every client, including the MCP server, goes through the same API and the same permission checks.

REST API

Covers everything the UI can do.

CLI

catalyst sandbox create ssh fork snapshot port-forward

SDKs

Python and TypeScript.

MCP server

AI agents such as Claude Code, Codex, and Cursor can create sandboxes, run commands, read files, and take snapshots through the Model Context Protocol. Each agent works with the same permissions as the API key it was given.

Webhooks

sandbox.created sandbox.started sandbox.stopped sandbox.deleted snapshot.ready quota.reached autostop.warning host.offline

Terraform provider Proposed

Manage sandboxes, images, and quotas as code.

Admin console

Where platform admins watch capacity, manage the fleet, and set the rules everyone else works within.

Capacity

GPUs and CPUs in use and free, by pool and by host.

Fleet view

Every sandbox, user, and organization, with admin overrides.

Configuration

Quotas, showback rates, sandbox types, and images.

Health

Platform status and alerts.

Lab hardware

Current inventory at Cybercore and the role each system would play in Catalyst.

GPU CPU and virtualization Storage Network and security

Figure 9. Lab hardware grouped by role across three racks. This is a logical layout. Physical placement in the Cybercore cage may differ.

System	Current OS	Role in Catalyst	Status
GPU compute
NVIDIA DGX H200	Ubuntu 22.04	Top tier for large models and 8 GPU work	Ready
Dell PowerEdge XE8545	Ubuntu 22.04.4	High-end GPU	Ready
Dell PowerEdge XE7740	Not installed	High-end GPU	Needs OS
Dell XR4520c	Ubuntu 24.04.3	Edge GPU	Ready
Dell C4140 ×4	Not installed	Fractional and shared GPU	Needs OS
HPE DL385 Gen10 Plus ×2	VMware ESXi 8.0.3	GPU	Decision
Dell PowerEdge R7525	VMware ESXi 8.0.3	GPU	Decision
Supermicro ARS-111GL-NHR	Not installed	Grace Hopper, ARM64 GPU	Needs OS
Developer workstations
Dell Pro Max with GB10	DGX OS	ARM64 developer and agent sandboxes	Ready
CPU and virtual machines
Dell VxRail G560 ×4	Harvester 1.5.1	VMs, desktops, Windows, and the Catalyst control plane	Ready
Dell XR4510c	Ubuntu 24.04.3	General compute	Ready
Dell R740xd	VMware ESXi 8.0.3	General compute	Decision
Dell R7515	Windows Server 2019	Directory and management services	Ready
Storage
Dell PowerStore	PowerStore Manager	Block storage for sandbox disks, snapshots, and clones	Ready
Dell PowerScale F200 ×3	OneFS 9.2.1.8	Shared files for datasets, model weights, and images	Ready
Dell Unity XT 480F	Unity OE	Backup and snapshot target	Ready
Network
Mellanox SB7800	MLNX-OS	InfiniBand fabric for multi-node GPU	Ready
Dell S4148F-ON ×3	OS10 10.5.2.8, 10.5.6.3	10/25 GbE data network	Ready
Juniper EX2300, Aruba 1930 ×3	Junos, Instant On	Out-of-band management	Ready
SonicWall NSa 6700, NSa 2700	SonicOS 7.1.1	Perimeter and ingress for the shared public IPs	Ready

Ready Can join as is Needs OS Needs a standard OS image first Decision Currently on ESXi, see notes

Technical notes

Answers to the open questions so far, and what we still need from the lab team.

Can containers use GPUs?

Yes. Kubernetes with the NVIDIA GPU Operator handles full GPUs, MIG slices, and time-slicing. Where customers need harder walls between each other, containers run inside lightweight VMs (Kata Containers) with the GPU passed straight through.

What should it be built on?

Harvester already runs on the VxRail nodes. It's Kubernetes and KubeVirt underneath, supports GPU passthrough and vGPU, and pairs with Rancher to manage the GPU clusters. Catalyst sits on top as the UI and API.

How far do snapshots go?

Disk snapshots and images are quick on PowerStore. Memory snapshots work for CPU sandboxes. GPU memory checkpointing is still experimental (NVIDIA cuda-checkpoint), so GPU sandboxes will resume from disk state at launch.

What happens to the ESXi hosts?

We recommend moving the two DL385s, the R7525, and the R740xd to Harvester or bare-metal Ubuntu with Kubernetes. That gives one control plane and removes VMware licensing from the picture.

What do we still need?

An OS image for the XE7740, the four C4140s, and the Grace Hopper node. Confirmed GPU models and counts for every host, so sandbox types can be finalized.

Note. Anything marked Proposed is an addition from Neuroscale AI. It can move to a later phase or be dropped.