Skip to Content
GuidesInfrastructure Management

Infrastructure Management

Quazzar Space gives you a structured way to model your entire infrastructure — projects, environments, servers, services, and the connections between them. This guide walks through how to set everything up.

Organizational Hierarchy

The platform uses a layered structure to keep your infrastructure organized:

Project └── Environment (production, staging, development) └── Group (logical grouping) └── SubGroup (optional further nesting) ├── Server (compute resource: VM, container, bare metal) └── Service (application or microservice)

Each layer inherits access controls from its parent, so you can manage permissions at the level that makes sense for your team.

Projects

A project is the top-level unit. Each project typically represents a product, client engagement, or business domain.

To create a project:

  1. Navigate to Projects and click Create Project
  2. Enter a name and description
  3. Invite team members and assign roles (Owner or Member)

Projects contain their own environments, team members, cost tracking, and settings. The number of projects you can create depends on your subscription tier.

Environments

Environments represent deployment stages within a project — for example, production, staging, and development. Each environment has its own:

  • Service and server inventory
  • Network configuration
  • Role-based access control (Administrator, Manager, Viewer)
  • Cost tracking and budgets
  • Service dependency map

To create an environment, open a project and click Add Environment. You can assign different team members different roles per environment, so a developer might have Viewer access in production but Administrator access in staging.

Groups and SubGroups

Groups let you organize services and servers within an environment by function, team, or architecture layer. Common groupings include:

  • Frontend — Web servers, CDN endpoints, load balancers
  • Backend — API servers, worker processes, message queues
  • Data — Databases, caches, search engines
  • Infrastructure — DNS, monitoring, logging services

SubGroups provide an additional level of nesting when you need finer-grained organization. For example, a “Backend” group might contain “Auth Services” and “Payment Services” subgroups.

Servers (Compute Resources)

Servers represent the actual compute resources your services run on. Each server has a type, cloud provider, and location.

Server Types

TypeDescriptionExamples
VMVirtual machineAWS EC2, GCP Compute Engine, Hetzner Cloud
ContainerContainer instanceDocker container, Kubernetes pod
Bare MetalPhysical serverHetzner Dedicated, OVH Bare Metal

Supported Cloud Providers

ProviderResource Types
AWSEC2, ECS, EKS, Lambda
Google CloudCompute Engine, GKE, Cloud Run
AzureVirtual Machines, AKS, Container Instances
HetznerCloud Servers, Dedicated Servers
OVHPublic Cloud, Bare Metal
DigitalOceanDroplets, Kubernetes

Adding a Server

  1. Open your target environment
  2. Click Add Server (or add within a group)
  3. Select the server type (VM, Container, or Bare Metal)
  4. Choose the cloud provider, region, and availability zone
  5. Enter resource specifications (CPU, memory, disk, instance type)
  6. Add optional tags for cost allocation and filtering

On Team plans and above, you can also use auto-discovery to automatically import servers from connected AWS, GCP, or Azure accounts.

Services

A service represents an application, microservice, or software component in your infrastructure.

Service Properties

When you register a service, you can track:

  • Name and description — Human-readable identification
  • Language/framework — Technology stack (Node.js, Python, Go, Java, etc.)
  • Version — Current deployed version
  • Repository URL — Link to the source code
  • Jira project — Integration for issue tracking
  • Ports — Exposed ports and protocols
  • Tags — Custom labels for filtering and cost allocation
  • Responsible owner — Team member accountable for the service
  • Server assignment — Which compute resource it runs on

Adding a Service

  1. Navigate to your environment (or a specific group)
  2. Click Add Service
  3. Fill in the service details — at minimum, a name is required
  4. Optionally assign it to a server and configure dependencies

Service Dependencies and the Service Map

Mapping dependencies between services helps you understand your architecture and assess blast radius during incidents.

To create a dependency link:

  1. Open a service’s detail page
  2. Go to the Dependencies tab
  3. Click Add Dependency and select the target service
  4. Specify the connection type (HTTP, gRPC, database, queue, cache, or custom)
  5. Add an optional description

The Service Map provides an interactive visualization of all services and their connections within an environment. You can zoom, pan, and click on any service or link to see details. This is particularly valuable during incident response to quickly identify upstream and downstream impact.

Networks

Networks define the network topology for your environment. Each network entry captures:

  • Name — A descriptive label (e.g., “production-vpc”)
  • CIDR block — IP address range (e.g., 10.0.0.0/16)
  • VLAN ID — Virtual LAN identifier
  • Gateway — Default gateway address

After creating a network, you can attach services and servers to it to document which resources share network connectivity.

Import and Export

Export your environment configuration as a JSON file for backup, migration, or replicating setups across projects. Available on Starter plans and above.

  • Export: Open an environment, go to Settings, and click Export Configuration. The export includes all groups, subgroups, servers, services, networks, and their relationships.
  • Import: Click Import Configuration and upload a previously exported JSON file. The import uses name-based matching, so you can safely re-import to update existing resources without creating duplicates.

This is useful for cloning a production environment structure into a new staging environment, or migrating configurations between projects.

Tips for Structuring Projects

Team SizeRecommended Structure
Small (2-5)Single project, 2-3 environments (dev, staging, prod)
Medium (5-20)One project per product, groups by team or domain
Large (20+)Multiple projects by business unit, subgroups by squad, strict role separation per environment

General best practices:

  • Use consistent naming conventions across environments
  • Tag servers and services with team ownership for cost attribution
  • Keep production environments restricted to Administrator and Viewer roles
  • Use groups to mirror your team structure or architecture boundaries
  • Document service dependencies early — the service map becomes more valuable as your infrastructure grows

Next Steps