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 Custom Lists it mounts, 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. Put it in a Custom List and mount the list on the profile:

bash
warden custom-list create household --display-name "Household"
warden custom-list add household gambling-site.example --deny
warden profile mount kids --custom-list household

The old warden profile allow and warden profile deny commands are retired in 0.44.0 and refuse to write. An exception for one device needs a profile of its own for that device. 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
`mount <id> --custom-list <list-id>`	Mount a Custom List on the profile
`unmount <id> --custom-list <list-id>`	Unmount it
`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 a device, group, subnet, schedule or `server.default_profile` still references it. The refusal does not name the reference; `journalctl -u purge-warden` has the validator’s report

add, set, remove and list-policy set|clear go through the running daemon over its socket, so they need the daemon up and an admin token (warden token generate). mount and unmount also go through the daemon, unless you pass --offline to edit the config files directly. list, show and list-policy show read the config on disk.

allow, deny and admin-rule add|remove still appear in --help but are retired. They fail without changing anything. Create the list with warden custom-list instead.

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.