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:
- Navigate to Projects and click Create Project
- Enter a name and description
- 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
| Type | Description | Examples |
|---|---|---|
| VM | Virtual machine | AWS EC2, GCP Compute Engine, Hetzner Cloud |
| Container | Container instance | Docker container, Kubernetes pod |
| Bare Metal | Physical server | Hetzner Dedicated, OVH Bare Metal |
Supported Cloud Providers
| Provider | Resource Types |
|---|---|
| AWS | EC2, ECS, EKS, Lambda |
| Google Cloud | Compute Engine, GKE, Cloud Run |
| Azure | Virtual Machines, AKS, Container Instances |
| Hetzner | Cloud Servers, Dedicated Servers |
| OVH | Public Cloud, Bare Metal |
| DigitalOcean | Droplets, Kubernetes |
Adding a Server
- Open your target environment
- Click Add Server (or add within a group)
- Select the server type (VM, Container, or Bare Metal)
- Choose the cloud provider, region, and availability zone
- Enter resource specifications (CPU, memory, disk, instance type)
- 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
- Navigate to your environment (or a specific group)
- Click Add Service
- Fill in the service details — at minimum, a name is required
- 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:
- Open a service’s detail page
- Go to the Dependencies tab
- Click Add Dependency and select the target service
- Specify the connection type (HTTP, gRPC, database, queue, cache, or custom)
- 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 Size | Recommended 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
- Cost Optimization — Track and reduce cloud spending across your infrastructure
- Monitoring & Alerts — Set up real-time monitoring for your services and servers