Platform Overview
How LaserData Cloud organizes deployments, access, networking, and management APIs
LaserData Cloud operates Apache Iggy deployments and the services around them. You manage deployments, teams, networking, and data access through the Console, CLI, or API. This page explains how those parts fit together.
Apache Iggy
Apache Iggy is a persistent message streaming platform written in Rust. Throughput and latency depend on hardware, configuration, and workload. General benchmark figures do not describe the Free tier. It supports TCP, QUIC, HTTP, WebSocket, consumer groups, replication, and optional encryption of message payloads.
A cluster is a group of servers that work together and replicate data between nodes.
Why LaserData Cloud
LaserData Cloud manages deployment, scaling, networking, security, monitoring, and connectors for Apache Iggy. You choose where deployments run and who can use them. The platform handles the tasks that keep them running.
Complete Isolation by Default
Paid deployments need access rules before clients can connect. Managed Free deployments include a global rule that you can restrict or replace. Warden starts management connections outbound, while application messages travel directly between clients and deployment nodes.
Enterprise-Grade Security
The platform protects management operations and connections:
- Warden starts all management connections outbound. Management needs no inbound ports, SSH, or remote access.
- The platform signs binaries and checks their signatures before execution. It signs operational tasks with Ed25519.
- The platform issues and rotates TLS certificates. Connections use encryption from end to end.
- Managed upgrades use signed binaries, controlled restarts, and rollback after failure.
Organization & Access Control
The resource hierarchy is Organization > Division > Environment > Deployment. APIs call an organization a tenant. For a first Free deployment, use the existing division and the starter environment instead of creating more groups.
RBAC, role-based access control, assigns permissions at each level. Four system roles are available: admin, developer, viewer, and billing. You can also create custom roles and apply division or environment overrides. Teams, invitations, and API keys are available through the API.
Full API Coverage
The API supports every operation available in the Console. The main API manages resources, and the deployment API operates deployments. Both use the same API keys and RBAC model. You can use them in CI/CD pipelines, Terraform providers, and custom integrations.
Built-in Connectors
Connectors move data between Iggy and external systems. They use compiled Rust plugins for systems such as PostgreSQL, Elasticsearch, Apache Iceberg, and Quickwit. Activate a connector in the Console, map its streams, and configure its instances.
Metrics and logs
Monitoring provides metrics, health reports, logs, and immutable audit trails, records that cannot be changed. You can send logs and traces to your own OpenTelemetry-compatible endpoint.
Key Features
The platform includes these tools and deployment choices:
- Stream UI browses streams, topics, messages, and consumer groups. Its Managed data area provides projections, queries, key-value storage, and forks when the managed data plane is enabled. The browser connects directly to Warden on the node, so Iggy data does not pass through the LaserData backend.
- Versioned configuration records changes to Iggy and connector configuration. You can create, activate, and restore versions.
- Pricing separates Compute, Storage, and Network charges across three paid managed tiers. There are no per-partition charges.
- Deploy to AWS or GCP, or use your own infrastructure through On-Premise.
- Choose Standard, Performance, or Enterprise, with adjustable storage and throughput. Free deployments are available for development.
- Paid deployments use three-node clusters with replication. Enterprise also supports Multi AZ, deployment across availability zones.
Deployment Models
Each model runs Iggy and Warden. The difference is who owns the infrastructure and where it runs. The management interface stays the same.
| Model | Infrastructure | Best For |
|---|---|---|
| Managed | LaserData's cloud | Fully managed, no infrastructure setup required |
| Bring Your Own Cloud (BYOC) | Your AWS/GCP account | Data sovereignty, your cloud bill |
| On-Premise | Your servers (any) | Private infrastructure with outbound control-plane access |
Connectors
The Connector Catalog lists the available sources and sinks. A source brings data into Iggy. A sink sends data from Iggy to another system.
Deployment Tiers & Storage
Paid managed deployments use Standard, Performance, or Enterprise. The tier sets starting monthly pricing, included features, and telemetry retention. Standard starts from $199, Performance from $999, and Enterprise from $2,999 per month on AWS, plus measured data transfer. Standard supports Network Drive. Performance and Enterprise also support Local NVMe. Throughput is a sizing and transfer-estimation input.
Free deployments use one node on shared infrastructure for development and testing. Read Tiers & Storage for the available configurations. Billing & Pricing explains monthly pricing and measured transfer.
Serverless, tiered storage, and a Kafka gateway are planned features. They are marked as coming soon and are not available yet.
Networking & Connectivity
Deployments receive a custom subdomain, such as your-cluster.laserdata.cloud, with automatic TLS. Connections use encryption from end to end. The networking features control which clients can reach a deployment.
| Feature | What It Does |
|---|---|
| Custom subdomain | Unique endpoint per deployment for connection strings, with automatic TLS |
| Access Rules | Allow specific IPs/CIDRs to reach deployment endpoints, per-protocol |
| VPC Peering | Private network path between your VPC and the deployment |
| PrivateLink | Expose the deployment as a VPC endpoint service |
| Public IP | Public (static Elastic IP with subdomain) or Private (no public IP, private networking only) |
Paid deployments need access rules before clients can connect. Managed Free deployments start with a global rule that you can restrict or replace. Free deployments use a configured 100 KB/s network limit. Shared hosts apply it to outgoing slot traffic. Paid deployments have no broker throughput limit.
Security
The security model covers management access, client access, and stored data:
- Paid deployments remain inaccessible to clients until you create access rules. Managed Free deployments include a global rule.
- Warden starts management connections outbound. The control plane does not use inbound ports, SSH, or remote access.
- The platform signs binaries and checks their signatures before execution.
- Every operational task uses an Ed25519 signature.
- The platform issues and rotates TLS certificates.
- Upgrades use signed binaries, controlled restarts, and rollback after failure.
- Application data travels directly between clients and deployment nodes. Stream UI uses a short-lived signed session with Warden's HTTP proxy. Access rules apply to the browser's IP address.
- GDPR support includes encryption of personal information at rest, data export, and the right to erasure.
See Security Architecture for the full model.
Observability
Monitoring provides these records for each deployment:
- Metrics for CPU, memory, disk I/O, messages, and client connections, grouped by node and runtime.
- Heartbeats, periodic health reports from managed runtimes.
- Centralized logs that you can search by node, runtime, level, and time range.
- Log and trace delivery to an OpenTelemetry-compatible endpoint.
- Audit logs that record every operation that changes state.
Plans
A deployment tier determines deployment pricing. Your account plan sets organization limits and feature access. New organizations start on Pro.
| Feature | Basic | Pro | Enterprise |
|---|---|---|---|
| Members | 10 | 100 | 1,000 |
| Divisions | 2 | 5 | 10 |
| Environments | 3 | 20 | 100 |
| Custom roles | 2 | 20 | 100 |
| Audit log retention | 7 days | 30 days | 365 days |
| BYOC | - | Available | Available |
| On-Premise | - | - | Available |
| Cluster (multi-node) | - | Available | Available |
| Multi-AZ | - | Available | Available |
| Private networking | - | Available | Available |
| Cross-region DR | - | - | Available |
Enterprise limits can be customized for a tenant. Contact us to arrange a custom plan. See Billing & Pricing for deployment tiers and account features.
API Architecture
LaserData Cloud exposes two API layers. Both are available through the Console or through API keys. The API for an operation depends on its scope.
Main API - api.laserdata.cloud
The main API manages tenants, divisions, environments, members, roles, API keys, notifications, deployment creation, and connector activation. It also manages billing and plans.
Supervisor API (Regional)
The Supervisor API operates deployments within one cloud provider and geographic area. It manages configuration, networking, monitoring, connectors, tasks, and backups. Deployments in the same cloud and area share an endpoint.
| Area | Cloud | Supervisor URL |
|---|---|---|
| US | AWS | supervisor-aws-us.laserdata.cloud |
| EU | AWS | supervisor-aws-eu.laserdata.cloud |
| AP | AWS | supervisor-aws-ap.laserdata.cloud |
| US | GCP | supervisor-gcp-us.laserdata.cloud |
| EU | GCP | supervisor-gcp-eu.laserdata.cloud |
| AP | GCP | supervisor-gcp-ap.laserdata.cloud |
How It Works
A deployment response includes supervisor_url, the endpoint for its cloud and area. Send operational requests for that deployment to this URL. The Console selects it automatically.
{
"id": 12345,
"name": "prod-cluster",
"cloud": "aws",
"area": "us",
"region": "us-west-1",
"supervisor_url": "https://supervisor-aws-us.laserdata.cloud",
...
}Both APIs use ld-api-key authentication and the same RBAC permission model.
OpenAPI Schemas
Each service publishes an OpenAPI 3.1 specification with a browser. Core, Audit, and Notifier share the dropdown at api.laserdata.cloud/docs. Each regional supervisor provides its own /docs endpoint. See API Reference for the supervisor URLs.
Error Responses
Both APIs return errors in an application/problem+json response, as defined by RFC 7807. Responses with 4xx and 5xx status codes use this structure:
{
"type": "about:blank",
"title": "Invalid Email",
"code": "invalid_email",
"reason": "Invalid email address",
"instance": "8f4a2b6c9d1e4f3a8b5c7d9e0f1a2b3c",
"field": "email",
"field_issues": [
{
"code": "invalid_email",
"reason": "malformed address",
"path": "email"
}
],
"status": 400,
"retryable": false
}| Field | Description |
|---|---|
type | RFC 7807 type URI. about:blank when no type is registered |
title | Short human-readable title derived from code |
code | Stable machine-readable error code (e.g. invalid_email, tenant_not_found, insufficient_permissions) |
reason | Long-form human explanation |
instance | Mirrors the ld-request response header. Quote this in support tickets |
field | Single field name when the error is bound to one field (legacy, still emitted for back-compat) |
field_issues | Array of structured per-field issues for validation errors. Each entry has code, reason, and an optional dotted path. Omitted on non-validation errors |
status | Mirror of the HTTP status code |
retryable | true for retryable conditions (408, 425, 429, 500, 502, 503, 504), false otherwise |
Validation failures return 400 Bad Request with one or more field_issues entries. Use those entries to show errors beside the relevant fields. Requests that change state (POST, PUT, PATCH) accept an optional idempotency-key header, which identifies repeated requests for safe retries. See API Reference for its behavior.
Naming Rules
Tenants, divisions, environments, deployments, channels, API keys, and similar resources share these naming rules:
- Use 1-100 characters.
- Start with an alphanumeric character.
- Use alphanumeric characters,
-,_,.,:, or spaces. Resources in the tenant hierarchy also accept,. - Avoid consecutive special characters. For example,
a--bis rejected anda-bis accepted. Hierarchy resources allow spaces beside a single special character. - Do not use leading or trailing whitespace.
The API rejects invalid names with 400 and describes the affected fields in field_issues.
Console
The Console manages deployments, connectors, networking, monitoring, configuration, members, roles, and audit logs. Use the pages below for each part of the platform.