Getting Started

Core Concepts

Understand the foundational building blocks of Pyrite Cloud—from global networking to stateful orchestration.

Pyrite Cloud is built on a modular architecture designed to abstract away the complexities of infrastructure management. By leveraging a few core primitives, you can deploy, scale, and secure applications globally in minutes.


The Pyrite Model

Pyrite Cloud operates on a "Security-First, Global-By-Default" philosophy:

  • Service-Oriented: Applications are decomposed into specialized service types.
  • Zero-Trust Networking: All communication is private by default using an identity-aware overlay.
  • Decoupled State: Compute scales globally, while persistent state remains region-bound for data integrity.
  • Managed Orchestration: Traffic routing, health checks, and failover are handled by the Pyrite Control Plane.

Service Types

Pyrite offers four specialized workload profiles, each optimized for specific performance and networking requirements.

Web Services

Best for: Stateless, high-concurrency public applications.

Web services are optimized for the modern edge. They feature built-in global load balancing and automated TLS termination.

  • Connectivity: Single-port (HTTP, gRPC, or WebSockets).
  • Scaling: Dynamic scaling based on request-per-second (RPS) metrics.
  • Global Reach: Automatically deployed across multiple regions to minimize latency.
  • Use Cases: Next.js frontends, Go/Rust APIs, and real-time Socket.io backends.

Pod Services

Best for: Stateful workloads and complex networking requirements.

Pods provide the flexibility of a traditional virtual machine with the agility of a container.

  • Connectivity: Multi-port support for HTTP, TCP and UDP traffic.
  • Static Identity: Support for dedicated IPv6 addresses.
  • Persistence: Direct integration with Persistent Volumes.
  • Use Cases: Self-managed databases, Redis clusters, game servers (e.g., Minecraft), or specialized protocols.

Worker Services

Best for: Asynchronous processing and background tasks.

Workers operate within the private network without public ingress, making them ideal for secure data processing.

  • Connectivity: No ports
  • Execution: Continuous running or event-driven execution.
  • Scaling: Scales based on resource utilization (CPU/RAM).
  • Use Cases: Image processing, Cron jobs, and message queue consumers.

Managed Postgres (Preview)

Best for: Mission-critical relational data.

A fully managed database experience with enterprise-grade reliability built in.

  • Architecture: Primary with automated read-replicas.
  • Efficiency: Integrated connection pooling (PgBouncer) for high-concurrency workloads.
  • Reliability: Automated backups and seamless failover.

Comparison Matrix

FeatureWebPodWorkerPostgres
Primary ProtocolHTTP / gRPCAny (TCP/UDP)-Postgres
Public Ingress
Private Network
Persistent Volume
Scaling MetricRequests/secResourcesResourcesManual/Plan
Region ScopeMulti-regionSingle-regionMulti-regionSingle-region
Architectural Guidance
  • Building an API or Website? Start with a Web Service.
  • Need a Database or Cache? Use Managed Postgres or a Pod Service.
  • Processing jobs in the background? Use a Worker.
  • Storing user uploads? Attach a Persistent Volume to a Pod.

Networking & Security

Private Global Mesh

Every service in your team is part of a Global Private Network. This is a default-deny, identity-aware mesh that allows services to communicate securely across regions without ever exposing traffic to the public internet.

Global Edge Routing

For public services, Pyrite utilizes BGP-based Anycast routing. When a user hits your URL, they are automatically directed to the nearest healthy instance, significantly reducing Time to First Byte (TTFB).


State & Persistence

Pyrite enforces a strict separation between Compute and State to ensure predictable performance.

  • Disk Storage: All services include a high-speed ephemeral disk for temporary files and caches.
  • Persistent Volumes: For data that must survive restarts, Volumes provide low-latency, block-level storage.
  • Regional Bound: To prevent latency issues and split-brain scenarios, persistent volumes are pinned to a specific physical region.