Organizations and networks

Organization and network are the entire ownership and grouping structure in Qarvix. There's no intermediate level like a "project" or a "workspace" inside an organization: an organization contains networks directly, and networks contain devices, static clients, and access rules.

If you need to group sites within one organization, there are two tools for that: a network (a separate VPN mesh) and a device group (a named set of devices for access rules, not tied to a single network). Below is which tool to reach for and why you shouldn't go looking in the interface for a "project" that doesn't exist.

In short

• Organization is the top and only boundary of ownership, access, and reporting.
• Network is an isolated WireGuard mesh inside an organization: its own CIDR, its own members, its own rules.
• A device group belongs to the organization, not to a single network, and is used for access rules (ACL) - it can include devices from different networks.
• What each person sees is determined by their role and which networks it's tied to, not by a separate grouping entity.
• Use separate organizations for multiple clients.
• Use several networks, or device groups inside one network, for branches of the same client - depending on whether they need VPN address isolation.

Organization

An organization answers the question: who owns the mesh and who's responsible for it. There's no shared layer above organizations - each one is autonomous, with its own users, roles, networks, license, and logs.

It's worth breaking out a separate organization if you need:

• separate administrators;
• separate users and invitations;
• independent logs and reports;
• different contract or license terms;
• different security policies;
• separation between a service company's clients.

Example organizations:

Don't use one organization for several independent clients if they shouldn't see each other's logs, users, devices, or reports. There's also no shared layer that ties several organizations of the same operator together: each organization runs its own billing, license, and access independently.

Network

A network is the main grouping tool inside an organization and, at the same time, a technical WireGuard mesh: its own CIDR, its own hub interface, its own members, and its own routing rules. Where other systems use a "project" or a "workspace," Qarvix uses a network to group sites.

Create a separate network if you need to:

• separate VPN address space: devices in one network shouldn't get addresses from another network's range;
• isolate members from each other by default, not only through ACL rules;
• configure exit node, peer mesh, and subnets differently for different groups of sites;
• be able to turn off an entire mesh with one action, without touching the rest of the organization's sites.

Good network names:

• office-demo;
• warehouse-cameras;
• retail-east;
• meters-prod;
• service-team-vpn.

Bad names:

• test;
• wg1;
• new-net;
• router;
• anton.

It's better for the name to reflect the purpose, the site, or the group of sites. This makes it faster to read logs, grant access, and avoid mixing up routes.

Device groups

If members need to be grouped not for VPN address isolation but for access rules, use a device group. A group belongs to the whole organization, not to a single network, so it can include devices from different networks and be reused across different ACL rules.

A device group is useful when:

• you need one rule to open access to several similar devices at once, e.g. every camera at a warehouse;
• devices logically belong to one line of business but are physically connected on different networks;
• the device list changes more often than access rules - the rule references the group, not a specific VPN IP.

A device group isn't a replacement for a network: it doesn't issue VPN addresses and doesn't create isolation by default - it only groups devices for ACL rules.

Roles and network binding

Splitting access between people - branches, teams, contractors - in Qarvix isn't set through a separate grouping entity, but through a role and its binding to specific networks.

In practice, this means: to make sure an engineer sees only one site rather than the organization's whole network list, the role they're invited through is bound only to the network they need. More on this in Users, roles, and SSO.

Typical structure models

A single site

Good for a pilot or a small site.

• Organization: Company;
• Network: office-net;
• Devices: the site's router, the administrator's static client.

Pros: fast to start, few entities.

Risk: if the number of sites grows, you'll need to plan ahead for whether to split them across networks or device groups.

Multiple branches of one client

Good for retail, offices, warehouses, cameras, and local services. There are two options, depending on whether branches need VPN address isolation from each other.

If branches must be fully isolated by network:

• Organization: Client;
• Networks: branch-almaty, branch-astana, branch-shymkent;
• Devices: branch routers, LAN routes, engineers' static clients.

If a shared VPN space is enough for the branches and separation is only needed for access rules:

• Organization: Client;
• Network: retail-all;
• Device groups: branch-almaty, branch-astana, branch-shymkent.

Both options share the benefit of a single client with centralized users and reports.

Risk of the first option: you need to plan VPN ranges ahead so they don't overlap. Risk of the second: without ACL rules between groups, devices from different branches may be able to see each other on the same network.

A service company with several clients

Good for a contractor that services sites for different customers. There's no shared layer above organizations for this scenario - each client gets their own organization, fully independent from the rest.

• Client A organization - a network with client A's sites;
• Client B organization - a network with client B's sites;
• Internal service mesh organization - Monitoring, Tests networks.

Pros: clients are isolated, reports and logs don't mix.

Risk: the service team needs to bind roles carefully to the right networks so that an engineer sees only the right clients - there's no shared login across organizations, each requires separate membership.

One mesh for cameras, sensors, and device APIs

Good for cases where local devices, not workstations, sit behind the router.

• Organization: Client;
• Network: cameras-and-sensors;
• Routes: the site's LAN subnet;
• Access: service team, monitoring, API integrations.

Pros: you can grant access to the devices you need over a tunnel, without a public IP or port forwarding.

Risk: LAN access needs to be restricted by rules, not opened up to every user.

How to choose a structure

Use a separate organization if the answer is "yes" to at least one question:

• does this client have separate users;
• do you need separate reports;
• must logs not be mixed;
• are contracts or licenses different;
• are administrators different;
• is strict isolation required.

Use a separate network if:

• you need a separate VPN range;
• devices shouldn't freely see each other by default;
• ACL, peer mesh, or exit node differ across groups of sites;
• routes to LAN subnets are different;
• the site needs to be switchable off as a single mesh.

Use a device group (within one network) if:

• you just need to group sites for ACL rules;
• VPN address isolation isn't required;
• the device list in the group will change often.

Bind a role to a specific network if:

• you need to limit which networks a given person can see;
• different teams work with different sites;
• a contractor only needs access to one network.

Naming recommendations

Since there's no intermediate grouping level in the system, a consistent naming format is what actually keeps the structure readable in lists, logs, and reports.

Use a consistent format: type-of-site-location.

Examples:

• retail-almaty-01;
• warehouse-astana-cameras;
• meters-kokshetau-prod;
• office-demo;
• service-laptops.

For devices, it helps to add the role:

• router-almaty-01;
• hub-prod;
• client-engineer-ivanov;
• camera-gateway-warehouse;
• plc-router-line-2.

Avoid temporary labels like new, old, test2 in names. They stop making sense quickly, and renaming a network or group after the fact is harder than naming it right the first time.

Access and responsibility

The structure of organizations and networks directly affects permissions.

The basic approach:

• organization administrators manage users, networks, and devices;
• engineers get access only to the networks they need, through a role bound to those networks;
• contractors get restricted access for the duration of the work;
• API tokens are used for integrations and automation;
• staff accounts aren't used as service accounts.

If you need to disable a staff member or contractor, it's important to understand where they have access: at the organization level as a whole, or at the level of individual networks through a role.

What to keep at the organization level

The organization level typically holds:

• users and invitations;
• roles and access policies;
• SSO settings, if single sign-on is used;
• API tokens for integrations;
• license parameters;
• shared logs and reports;
• naming rules and operational agreements.

At the network level, it's better to keep what belongs to a specific group of sites: devices, routes, device groups and ACL, peer mesh, exit node, and LAN/API access.

Checks before going into production

Before putting a mesh into operation, check:

• the organization has a clear name;
• networks don't use overlapping VPN ranges;
• sites' local LAN subnets don't conflict with each other;
• users don't get extra access beyond the networks they need;
• contractors have a clear time and access boundary;
• events are visible in the logs;
• reports can be generated for the right organization or network;
• it's clear who owns each network and each device.

Common mistakes

Looking in the interface for a grouping level above organization

There isn't one in Qarvix: an organization contains networks directly. If you need extra structure, use several networks or device groups inside a network - depending on whether VPN address isolation is needed.

All clients in one organization

This is faster to start with, but permission, log, and reporting problems show up later. Use different organizations for independent clients.

One network for all sites with no grouping

Sometimes this is convenient, but more often it creates unnecessary connectivity between sites. If sites need to be isolated, create separate networks, or at least split devices into groups and restrict connectivity with ACL rules.

No consistent naming format

After a few months, names like test, router2, new branch stop explaining anything. It's better to agree on a naming format up front.

Giving a contractor administrative access

For one-off jobs, it's better to restrict access by binding a role to a specific network and setting an expiry. Administrative roles are best reserved for people who actually manage the mesh.

Subnet overlaps not checked

If a VPN range or a LAN subnet matches another network, routing can behave unpredictably. Check the address plan before connecting production sites.

Related sections

• First steps in Qarvix - the general first-launch route.
• Users, roles, and SSO - how to grant and revoke access, and bind roles to networks.
• Networks, routes, and ACL - how networks, device groups, routes, and access rules are structured.
• Logs and reports - how to review actions and prepare operational material.