First steps in Qarvix

This page walks you through the first working route in Qarvix: choose an organization, create a network, add a device or a static client, check connectivity, and grant access to your team.

If you just need to connect one device by the book, use Quick device onboarding. This page covers the broader context: how to put together a first managed mesh in a way that's easy to maintain going forward.

What you'll end up with

After completing these steps you'll have:

• an organization selected, with devices assigned to it;
• your first Qarvix WireGuard network;
• at least one network member: a managed router, a hub, or a static client;
• a clear VPN address for every member;
• a basic check of online status and logs;
• access granted to a user or the service team;
• an understanding of where to look when there are connectivity issues.

The basic model

In Qarvix it helps to think not in terms of separate VPN files, but of a managed mesh.

The main idea: you set up the organizational and network structure first, then add devices and users into it. That makes access, logs, reports, and maintenance easier to manage.

Step 1. Choose an organization

After logging in, check which organization you're working in. This matters: networks, devices, users, logs, and reports are all scoped to the selected organization.

Use separate organizations if you need to separate:

• different legal clients;
• independent operations teams;
• sites with different security rules;
• a pilot mesh and a production mesh;
• lines of business or sites that need their own reports.

If you're new to the system, start with one organization and one network. There's no need to complicate the structure up front.

Step 2. Create your first network

A Qarvix network is a managed WireGuard mesh. Members live inside it: routers, the hub, static clients, and other nodes.

When creating a network, give it a clear name and a VPN range.

Good names:

• home-net;
• office-demo;
• retail-kokshetau;
• cameras-warehouse;
• meters-prod.

For a first test, you can use a range like:

10.100.0.0/24

Before going to production, check that the VPN range doesn't overlap with local subnets at your sites. Subnet overlaps are one of the most common reasons a device shows online but the service you need stays unreachable.

Step 3. Add the first network member

There are two main options.

Managed device

Pick this option for a router or gateway that will run the Qarvix agent.

A member like this holds two links:

• a WSS management channel for commands, configuration, heartbeats, and state updates;
• a WireGuard tunnel for user traffic.

This is the primary scenario for sites behind NAT, a mobile carrier, a regular SIM card, or a closed network with no public IP.

Static client

Pick this option for a laptop, phone, metering server, or workstation that just needs a regular WireGuard profile with no agent.

A static client doesn't hold a WSS channel, so its online status is determined by the freshness of its WireGuard handshake at the hub. That's normal: the absence of an agent heartbeat for this kind of client isn't treated as an error.

Step 4. Check the VPN address and status

After connecting, open the device list or the network detail page.

Check that:

• the member shows up in the right network;
• the VPN IP was issued from the expected range;
• the status matches the member's type;
• for a managed device, the agent version, model, and firmware are visible, if the device reports this data;
• Last seen is updating;
• there are no repeating connection errors in the device log.

If the device is online but access to a local service doesn't work, don't start by reinstalling the agent. Check routes, ACLs, subnet routes, peer mesh, and subnet overlaps first.

Step 5. Decide whether you need LAN access behind the router

The fact that a router is connected to Qarvix doesn't always mean the whole local network behind it should be opened up.

Typical options:

For managers and service teams this looks simple: the site is connected once, and access to the LAN subnet it needs is turned on centrally in the dashboard.

Step 6. Grant access to a user or team

Don't hand out one VPN profile to everyone. In Qarvix, access is better granted personally or through a role.

A minimal scheme:

• an administrator manages the organization, networks, and users;
• an engineer gets access only to the sites they need;
• the service team sees its own devices and logs;
• a contractor gets temporary or restricted access;
• an integration account uses an API token, not a person's password.

If your company uses single sign-on, plan to connect OIDC SSO. If access is granted manually, turn on 2FA for accounts with administrative rights.

Step 7. Check logs and reports

After the first connection, check not just that connectivity works, but also the trail of events.

Look at:

• the audit log: who created the network, device, token, or access rule;
• the device log: when the agent connected, received its configuration, and applied the settings;
• the device list: current statuses and last time seen online;
• reports: what can be exported for operations, oversight, or incident review.

Reports matter beyond the technical team. For a manager, they're proof that sites are connected, access is centrally managed, and user actions can be reviewed.

Step 8. Check access to device APIs

If there are cameras, PLCs, meters, sensors, or local services behind the router, Qarvix can give access not just to connectivity, but to these devices' APIs over the tunnel.

Examples:

• open a camera's web interface without port forwarding;
• pull data from a meter at its local address;
• reach a controller API on the site's LAN subnet;
• connect a monitoring service to devices behind the router;
• give a contractor access to only the API they need, without exposing the whole network.

It's best to treat this kind of access as its own scenario: who is reaching in, to which address, over which protocol, and with what restrictions.

First-launch checklist

• The correct organization is selected.
• The network was created with a non-overlapping VPN range.
• The device or client was added to the right network.
• The VPN IP was issued correctly.
• The managed router holds both WSS and WireGuard.
• The static client has a fresh WireGuard handshake.
• The LAN route was added only where it's actually needed.
• ACL and default access match the security policy.
• Users get personal access.
• The logs show connection and configuration-apply events.
• It's clear which services are reachable over the tunnel for the site.

Where to go next

• Quick device onboarding - step-by-step connection for a router or a static client.
• Organizations and networks - how to split clients, branches, and teams.
• Users, roles, and SSO - invitations, roles, 2FA, API tokens, and OIDC SSO.
• Devices and VPN addresses - statuses, tokens, clients, and addresses.
• Networks, routes, and ACL - exit node, peer mesh, subnet routes, and access rules.
• Device API over the tunnel - access to local services behind the router.
• Logs and reports - operational checks and oversight material.