Hands-On Demo: Build a Policy from Scratch

This is a guided lab. In about 15 minutes you’ll create two groups, connect them, lock the connection down to a single port, and watch the default-deny rule actually block traffic — all on a throwaway setup you can tear down afterwards. It’s the fastest way to get how Rabtly access control behaves.

Time: ~15 minutes · Difficulty: beginner · You’ll learn: groups, connections, direction, port limits, and testing

Try it right here

This is a live playground — the same React Flow canvas the real dashboard uses, running on throwaway local state. Nothing here touches your network. Drag from one group to another to connect them, click a connection to change its direction or restrict it to Postgres, add a group, and watch the reachability verdict update at the bottom. The written steps below mirror exactly what you can do in this canvas.

This embedded version is a simplified teaching model. The real Access Control page adds Map/Matrix/List views, multi-port rules, descriptions, saved policies, and JSON export — but the core gesture (connect groups, default-deny everything else) is identical.

The scenario

We’ll model a tiny company called Acme:

A developer’s laptop that should be able to reach a database — but only on the Postgres port.
A database server that holds sensitive data and should never start connections back out to laptops.

By the end, laptop → database will be allowed on tcp/5432 only, and everything else will be blocked — without you ever writing a single “deny” rule.


   ┌──────────┐   tcp/5432 only    ┌────────────┐
   │ laptops  │ ─────────────────▶ │  database  │
   └──────────┘    (one-way →)     └────────────┘
        ▲                                 │
        └──────────  blocked  ◀───────────┘
                 (default-deny)

Before you start

You need two devices enrolled in your Rabtly network and an account that can edit access control. If you don’t have two real machines handy, a laptop plus a small cloud VM (or even a second laptop) works perfectly for the demo. See Add your first device if you haven’t enrolled any yet.

Pick which enrolled device will play the laptop and which will play the database — you’ll sort them into groups in Step 2.

Step 1 — Open Access Control

Go to the page

In the dashboard sidebar, click Access Control. You’ll land on the Map tab. Right now you’ll likely see a single default node containing all your devices — that’s the starting point: one group, everyone can talk to everyone.

Note the three tabs

At the top you’ll see Map, Matrix, and List, plus a Groups tab. We’ll mostly use Groups and Map in this demo, but feel free to peek at Matrix and List — they show the same policy a different way.

Step 2 — Create two groups

Open the Groups tab

Click Groups, then New group.

Create `laptops`

Name: laptops (lowercase)
Description: Developer machines (optional)
Colour: pick anything — colour is just a visual aid
Click Create group.

Create `database`

Click New group again and repeat with the name database.

Assign your devices

On the laptops group, click Manage devices, tick the device you chose as the laptop, and Save changes. Do the same on database for your database device.

Any device you don’t tick stays in default. That’s fine — for this demo only your two chosen devices need to move.

You now have three groups: laptops, database, and default. No connections exist between them yet, so — apart from devices sharing a group — nothing can reach anything. Let’s prove that, then open up exactly what we need.

Step 3 — Prove default-deny (the “before” shot)

Before adding any rule, let’s confirm the baseline.

Open Test reachability

Click Test reachability in the top-right.

Test laptops → database

Set source = laptops, destination = database. The verdict should be Blocked.

That’s default-deny working: two different groups, no connection, no access. Keep this in mind — we’re about to change only this one pair.

Step 4 — Connect the groups

Now the core gesture. We’ll let laptops reach database.

Switch to the Map tab

You’ll see your group nodes.

Draw the connection

Hover the edge of the laptops node until a handle appears, then drag from laptops to database and release. A new edge appears between them.

Notice it defaults to two-way

The fresh connection is two-way (↔) — both groups can currently initiate. We’ll tighten that next.

Prefer clicking to dragging? Open the Matrix tab and click the cell where the laptops row meets the database column. Or use List → Add connection and pick the two groups. All three do the same thing.

Step 5 — Make it one-way and Postgres-only

The database should never start connections back to laptops, and laptops only need Postgres. Let’s encode both.

Select the connection

Click the edge between laptops and database to open the inspector on the right.

Set the direction to one-way

Change the direction to laptops → database (the → option). The database can no longer initiate back to laptops.

Restrict the ports

Under ports, switch from All ports to Specific, then add one row:

Protocol: tcp
Port: 5432

The edge label should now read something like tcp/5432.

Add a note (optional)

Type a short description like Dev laptops reach Postgres so future-you remembers why this rule exists.

Save

Click Save in the policy save bar. Changes apply immediately — no restart.

Step 6 — Test the “after” shot

Open Test reachability again and try a few pairs to see the policy from every angle:

Source	Destination	Expected verdict	Why
`laptops`	`database`	One-way	We allowed exactly this, on `tcp/5432`
`database`	`laptops`	Blocked	The connection is one-way `→`; the reverse was never allowed
`laptops`	`laptops`	Same group	Same-group traffic is always allowed
`laptops`	`default`	Blocked	We never connected these — default-deny still holds

That fourth row is the important lesson: adding one connection opened up only that pair. Everything else stayed locked down automatically.

Step 7 — See it for real (optional)

Want to watch the firewall actually enforce it? From the laptop device, try reaching the database device by its Rabtly IP or MagicDNS name:

Connecting on port 5432 (e.g. a psql client, or nc -vz <database> 5432) → succeeds.
Connecting on any other port (e.g. SSH on 22) → times out / refused, because the rule only allows tcp/5432.
From the database device, trying to reach the laptop → blocked, because the connection is one-way.

nc -vz <host> <port> (netcat) is a quick way to probe a single port without installing anything heavy. A connection that hangs and times out is the firewall doing its job.

Step 8 — Clean up

This was a demo, so feel free to undo it:

Remove the connection

On the Map (or List) tab, select the laptops → database edge and delete it, then Save.

Delete the groups

In the Groups tab, delete laptops and database. Their devices fall back to default automatically.

Before deleting, click Export to download the policy as JSON — a nice way to keep a record of what you built, or to diff against a real policy later.

What you learned

Groups + connections are the whole model — sort devices, then allow group-to-group traffic.
Default-deny means a new group reaches nothing until you connect it; you never write a deny rule.
Direction matters — → lets one side initiate without opening the return path.
Port limits shrink a connection to exactly the service that needs it (tcp/5432).
Test reachability lets you verify a change against the live policy before — and after — you save.

Next steps

How Access Control works (reference) →Set up a team network →CLI reference →