Create profiles

Under review — wording may still change.

Carve exceptions out of the default profile the daemon already created.

What this step does

warden init already wrote one profile, default, and pointed server.default_profile at it — unless you answered none at that prompt. Every address that matches no device, group, or subnet lands there. It’s the filter that’s already running, before you type a single profile command.

A profile is the policy Warden applies once it has picked one: which lists it enforces and in which direction, which admin rules it carries, whether it blocks everything (block_all), SafeSearch, and the shape of a blocked answer. This page only walks the commands that create and wire up profiles — the full field list lives on the profile schema.

Decide which lists apply

This is the part that changed. A subscribed list carries a base direction on its own [[blocklists]] row — deny unless the list says otherwise. A profile overrides that default per list: profiles.<id>.lists maps a list id to deny, allow, or ignore. Leave a list out of the map and the profile just inherits its base.

bash

warden profile list-policy set kids social deny

The same override, written by hand:

config.toml
toml
[profiles.kids]
lists = { social = "deny" }

list-policy clear is not the same as list-policy set … ignore. Clearing drops the key, so the pair follows the list’s base wherever that goes next. ignore is a standing override that survives a later change to base.

If the same profile also mounts a custom list, declare custom_lists before lists in the [profiles.<id>] table — custom_lists is a bare array and lists is an inline table, and TOML can’t emit a bare value after a table in the same block.

Create a profile

Add the profile, then adjust whichever fields the household needs — here, a different blocked-answer shape:

bash
warden profile add kids --display-name "Kids"
warden profile set kids block_response nxdomain

A new profile filters nothing until something points at it. Wire it up wherever the address actually lives:

A single device — pin it in Manage devices.
A device group — the group’s priority picks the profile; see groups.
A whole subnet — Subnets sets the profile a CIDR falls back to.

One-off exceptions don’t need a profile

A single domain doesn’t earn a new profile. warden profile allow and warden profile deny write an [[admin_rules]] row and reference it from that profile in one step:

bash

warden profile deny kids gambling-site.example

An exception scoped to one device belongs on the device instead — see custom rules.

Profiles are flat

Profiles don’t inherit or extend each other — no extends, no merging. Two profiles that should share most of their policy each declare it in full.

CLI reference

Verb	Does
`list`	List all profiles with summary stats
`show <id>`	Full details for one profile, including mounted custom lists and the list-policy block
`add <id> --display-name <s>`	Create a profile
`set <id> <field> <value>`	Set one field — `display_name`, `block_response`, `blocked_ttl`, `block_all`, or an `ecs.*` field
`allow <id> <domain>` / `deny <id> <domain>`	Add (or, with `--remove`, drop) a one-off admin-rule exception
`admin-rule add\|remove <id> <rule-id>`	Attach or detach an existing `[[admin_rules]]` row
`list-policy set\|clear\|show <id> [<list-id> <deny\|allow\|ignore>]`	Override, revert to, or inspect the direction a list takes on this profile
`remove <id>`	Delete — refused while any device, subnet, or schedule still references it

warden profile custom-lists does not exist — mounting a custom list is a TUI operation, or a hand-edited custom_lists = [...] in the profile’s table.

In the TUI

Filters (4, or g p from anywhere) opens on Profiles — it’s that section’s default leaf. Add, edit, and delete profiles there without touching the CLI.