LaserData Cloud
Getting Started

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.

ModelInfrastructureBest For
ManagedLaserData's cloudFully managed, no infrastructure setup required
Bring Your Own Cloud (BYOC)Your AWS/GCP accountData sovereignty, your cloud bill
On-PremiseYour 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.

FeatureWhat It Does
Custom subdomainUnique endpoint per deployment for connection strings, with automatic TLS
Access RulesAllow specific IPs/CIDRs to reach deployment endpoints, per-protocol
VPC PeeringPrivate network path between your VPC and the deployment
PrivateLinkExpose the deployment as a VPC endpoint service
Public IPPublic (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.

FeatureBasicProEnterprise
Members101001,000
Divisions2510
Environments320100
Custom roles220100
Audit log retention7 days30 days365 days
BYOC-AvailableAvailable
On-Premise--Available
Cluster (multi-node)-AvailableAvailable
Multi-AZ-AvailableAvailable
Private networking-AvailableAvailable
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.

AreaCloudSupervisor URL
USAWSsupervisor-aws-us.laserdata.cloud
EUAWSsupervisor-aws-eu.laserdata.cloud
APAWSsupervisor-aws-ap.laserdata.cloud
USGCPsupervisor-gcp-us.laserdata.cloud
EUGCPsupervisor-gcp-eu.laserdata.cloud
APGCPsupervisor-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
}
FieldDescription
typeRFC 7807 type URI. about:blank when no type is registered
titleShort human-readable title derived from code
codeStable machine-readable error code (e.g. invalid_email, tenant_not_found, insufficient_permissions)
reasonLong-form human explanation
instanceMirrors the ld-request response header. Quote this in support tickets
fieldSingle field name when the error is bound to one field (legacy, still emitted for back-compat)
field_issuesArray of structured per-field issues for validation errors. Each entry has code, reason, and an optional dotted path. Omitted on non-validation errors
statusMirror of the HTTP status code
retryabletrue 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--b is rejected and a-b is 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.

On this page