Platform architecture

Acasia Cloud is organized into two surfaces — the Developer Portal and Settings — built on a shared resource model. Resources follow a layered hierarchy: Organization → Machine → Cluster → Inference Endpoint → Application. Desired state lives in Cloud; the control plane installed on your hardware applies it to the runtime and reports status back through logs. The resource model is the same for capacity rented through the Marketplace and capacity held under a bare metal reservation. What differs is scope and depth. Marketplace rentals always run the control plane, so Cloud reports per GPU — scoped to the GPUs you rented — and can drive cluster and deployment changes. Bare metal customers hold root access to their machines and run their own stack, so Cloud reports at the node level across the machines reserved for them, unless the control plane is installed.

Platform layers

Developer Portal

The Developer Portal is the organization-facing workspace for using GPU capacity. Developers and organization administrators use the Developer Portal to:

• View available clusters
• Inspect allocated machines
• Create clusters from available machine capacity
• View cluster hardware details
• Attach SSH keys
• Connect to clusters
• Deploy inference endpoints
• Manage active and terminated model deployments
• Create API keys for programmatic access

Settings

Settings centralizes user and organization administration. Settings includes:

• Profile management
• Password and security settings
• Billing and Stripe-managed payment updates
• Reusable SSH key management
• Organization user invitations and removals
• Organization metadata updates

Some settings are available to all users. Organization-level settings, billing settings, and user management should be restricted to organization administrators or approved billing users.

Resource model

Acasia uses a layered resource model. Each layer scopes the layer below it. Organization → Machine → Cluster → Inference Endpoint → Application or API Consumer

Organization

An organization is the account boundary in Acasia Cloud. It represents a customer, partner, or internal team, and every rental or reservation is owned by one. Organizations scope:

• Users
• Machines
• Clusters
• Inference deployments
• SSH keys
• API keys
• Billing settings
• Logs

Machine

A machine is a GPU-backed compute resource registered in Acasia Cloud. A machine may represent:

• A single GPU server
• A DGX-class system
• Hardware under a bare metal reservation
• Capacity rented through the Marketplace from a third-party hardware owner
• A partner-supplied host

Machines expose resources such as GPU count, GPU model, CPU, RAM, storage, network capacity, status, and control plane state.

Cluster

A cluster is a deployable allocation of GPU, CPU, RAM, and storage carved from one or more machines. A cluster is the unit a workload runs on, and it can be resized as the workload changes. Clusters move through a defined set of lifecycle states.

Inference endpoint

An inference endpoint is a deployed model service running on a cluster. Models are selected from the model library in Acasia Cloud and exposed over a REST API that applications, agents, and workflows call.

Desired-state operating model

Acasia separates the control-plane request from the runtime operation. Cloud records desired state; the control plane applies or verifies it on the underlying machine and reports back.

1. User creates a cluster
2. Acasia Cloud records the desired cluster allocation
3. The control plane applies or verifies the allocation on the machine
4. Cluster status updates in the Developer Portal
5. Logs record the result

This separation makes it easier to track changes, troubleshoot failures, and audit platform activity. It also means a discrepancy between what was requested and what the hardware actually did is visible as a state, rather than hidden.

Developer workflow architecture

A typical developer workflow moves through the following path:

1. Confirm organization context
2. Review available machines and clusters
3. Create or select a cluster
4. Attach an SSH key if direct access is needed
5. Deploy an inference endpoint
6. Create or use an API key
7. Connect the application or workflow

Credential architecture

Acasia uses two credential types: SSH keys and API keys.

SSH keys

SSH keys authorize secure shell access to clusters. SSH access depends on:

• An active cluster
• A valid public SSH key attached to the cluster
• The matching private key available locally
• Network access to the cluster host
• Correct organization context and permissions

API keys

API keys authorize programmatic access to Acasia services. API keys should be:

• Named by application, environment, or owner
• Stored in a secrets manager
• Rotated periodically
• Removed when no longer needed
• Never committed to source code

Operational visibility

Acasia Cloud records platform activity through logs and status fields. Logs should be used to investigate:

• Organization creation
• User invitations
• Machine registration
• Cluster creation, edits, and deletion
• Inference deployment activity
• SSH key changes
• API key creation or removal
• Billing updates
• Control plane reflection events
• Failed or out-of-sync operations

Example end-to-end flow

1. Developer creates an API key
2. Developer deploys a model endpoint on an active cluster
3. Application sends a request to the Acasia endpoint
4. Endpoint runs the model on the allocated GPU cluster
5. Model returns structured output
6. Application renders the result to the user
7. Logs and endpoint status support monitoring and troubleshooting

Design principles

One platform, two purchase paths

Marketplace rentals and bare metal reservations resolve to the same resource model and the same Acasia Cloud surfaces. Depth of reporting and control follows what is installed on the hardware, not which page you are on.

Organization-scoped control

Resources, users, credentials, clusters, endpoints, and billing settings are scoped to an organization. This keeps customer environments separated.

Human-controlled infrastructure

Developers initiate changes intentionally. High-impact actions such as deleting clusters, users, or endpoints should require dependency review.

Developer self-service

Developers can use allocated compute without needing elevated access. The Developer Portal gives them the ability to inspect clusters, deploy endpoints, manage credentials, and connect applications.

Auditability

Important actions are visible through logs. This helps teams understand what changed, who changed it, and whether the runtime successfully reflected the requested state.