Domains & websites
Every domain where it belongs
Domains, websites and hosting accounts attach to the client: one chain from name to server. The domain page puts what public DNS answers, what Cloudflare expects and what your registrar's register says side by side. And that register has a say in the invoice, so you bill only the domains you actually renew.
The chain, per client
A client's online infrastructure is a fixed chain: the domain, optionally a website, and the hosting it runs on. All three attach to the client and surface as panels on the client page, so one place shows what sits where. A domain gets at most one website, on the root (@) or on www, with a technical owner recorded by name: your agency, the client, an employee or a contact person. Hosting is its own entity (Instellingen → Hosting) and may sit without a client, because shared infrastructure is a real state rather than a missing field. All three inherit your own extra fields, keep an activity trail of who changed what and when, and travel to a spreadsheet and back, with bulk editing across a whole selection.
- Domain: client, status, start date, registrar, DNS and e-mail provider, registry and e-mail contact
- Website: on @ or www, linked to a hosting account, with an uptime flag per site
- Hosting: provider, IP address and a responsible owner; no client means shared
DNS that keeps itself current
For every domain a plain resolver reads public DNS: nameservers, DNSSEC and MX records. That works for every domain, not only the parties we integrate with. A new domain is fetched right after you add it and refreshed every night, so the page stays right without anyone pressing anything; the Verversen button is there anyway, for the moment just after a change. An unreachable domain reads as "no data" and never breaks the rest of the batch. Paste a whole URL into the name field and it is reduced to the bare domain: "https://WWW.Example.NL/pagina" becomes example.nl, on import too, so you never get a second row for a domain you already had.
- Nameservers, exactly as they resolve in public DNS
- DNSSEC: yes, no, or not-yet-known — "never checked" is not "off"
- MX records in priority order, so you see where mail goes
Cloudflare belongs to the domain, not to a second browser tab
Cloudflare accounts are rows under Instellingen → Cloudflare, not one setting per installation: your agency has its own and some clients bring theirs. You paste a scoped API token (stored encrypted, never handed back) and press Token controleren; that screen writes down what the token may actually do, so a missing scope reads there as "niet toegekend" instead of surfacing three screens away as a button that doesn't work. Zones ophalen pulls the zones, the Pages projects and the Cloudflare Registrar list in one action and reports how many could be matched to a domain; whatever didn't match is shown rather than hidden. On the domain itself, "Koppelen aan Cloudflare" adopts an existing zone first and only creates one when there is none, with an "Alleen een bestaande zone koppelen" option for taking over a client's existing setup. The panel puts "Cloudflare verwacht" beside "Publieke DNS antwoordt" and says in one sentence whether the nameservers already point the right way.
- DNS records read live from Cloudflare: A, AAAA, CNAME, TXT, MX, NS, SRV and CAA, with TTL, proxying and a note
- Export a zone as a BIND zone file or as CSV, straight from the panel
- Cloudflare Pages: link a hostname to a project, even when DNS lives elsewhere
- Three separate permissions, so looking at DNS is not the same act as changing it
A redirect with a mechanism behind it
"Doorverwijzing" was a status label for years: the domain said redirect and the actual work happened somewhere else. Now it is a Redirect Rule schakl. puts on the Cloudflare zone itself, with the target URL and the kind of redirect beside it — a permanent one carries a warning, because browsers remember it. By default schakl. adds the records the redirect needs, because a rule on a zone with no proxied record never fires: that is exactly the failure that looks like a Cloudflare problem and isn't one. "Controleren bij Cloudflare" then goes and looks, and names what it finds in plain sentences: the rule was changed in the Cloudflare dashboard (with which fields differ), it is gone, it was never pushed, the zone is paused, or another rule may win first. Conflicts are reported and never quietly resolved; schakl. does not touch somebody else's rule.
- 301, 302, 307 or 308, carrying the path and query string if you want
- www and other subdomains too, with the records the redirect needs added alongside
- A redirect pointing back into its own match set is refused, not saved
The register knows what DNS cannot
Public DNS tells you where a domain points; it does not tell you when it expires, whether the transfer lock is on, who the registrant is, or what the registry has actually delegated. Those four facts come from your registrar's register. For OXXA you keep reseller logins under Instellingen → OXXA, pull the whole register in one call, and get a Registrar (OXXA) panel on the domain page with Verloopt, Houder, Verhuisslot, Automatisch verlengen, DNSSEC and the nameservers, plus warnings in plain language: this domain expires soon, the transfer lock is off, the register holds different nameservers than the ones we pushed. The most valuable outcome of the first sync sits behind the "Alleen niet-gekoppelde" filter: domains you pay for every year that schakl. — and therefore your invoice — knew nothing about. And "Nameservers wijzigen bij OXXA" removes the last manual step from the Cloudflare hand-off: the box opens pre-filled with the nameservers Cloudflare expects, and pushing the same ones twice changes nothing and says so.
- What the register delegated, what we pushed and what public DNS answers are three separate facts; a difference is reported, never overwritten
- Nameserver groups are shared objects at OXXA, so schakl. creates one and never edits somebody else's
- Stated plainly: the OXXA integration is written from OXXA's own API documentation and has not yet run against a live reseller login — the same holds for the Cloudflare Registrar half
Bill only the domains you actually renew
An agency's domain list is a mixture: names you renew every year and names the client registered themselves and merely asked you to point somewhere. Only a register can tell those apart; a zone cannot, because Cloudflare answers DNS for plenty of domains it does not hold. So Facturatie on a domain is three-state, with a line underneath naming which register decided ("Staat in het register van OXXA, dus dit domein wordt gefactureerd"), and nothing changes while no register has been read: an installation that invoices domains today invoices exactly the same ones tomorrow. What gets charged follows the TLD rates with their price history, where an increase is shown as a preview per extension before anything is written; a nightly run rolls each domain a year forward and puts the renewal line on a draft invoice. Domains, websites, hosting, Cloudflare and OXXA are extension modules: the core of schakl. is open source (AGPL) and modules like these run on a licence key entered under Instellingen → Licentie; when it lapses they go read-only, so the register, the expiry dates and the warnings stay readable while nothing is written outward any more.
- Wel factureren: the yearly renewal goes to the client
- Niet factureren: the client registered it themselves and we charge nothing for it
- Volg het register: the register decides, and the Gefactureerd column prints "volgens register" beside the answer
What runs on the site, and whether it is up
Cloudflare is something a domain has; WordPress and the monitor are things a *website* has, so they sit one level down the tree. One WordPress Application Password per site opens four surfaces on the same host, and supplies Rank Math's AI visibility as a marketing source along the way: how often a client's brand is named and linked in AI answers. Uptime Kuma turns the "monitor this" checkbox into a real record, with a client, a profile, a history and a place on the client page beside the domain and hosting account it depends on. And because somebody will eventually edit a monitor in Kuma itself, what schakl. decided and what it last observed are stored separately, so drift is something you can see rather than something silently overwritten.
- The WordPress password belongs to an administrator, so only admins may manage it and a client login never reaches it
- A client's monitor server behind a firewall works too: the traffic simply runs the other way
- Existing monitors are adopted rather than recreated
Want to know more?
The documentation describes every module in detail, from installation to permissions.