Homelab-manager/INTEGRATIONS.md

Integration & DNS provider access requirements

What credential to create in each target system, and the minimum access it needs, when adding an integration or DNS provider in Homelab Manager (Integrations → Add integration, or DNS → Add provider). All credentials are entered in-app and encrypted at rest — nothing is read from environment variables.

Every adapter listed here performs write actions (starting/stopping things, editing DNS records, etc.), not just reads — a read-only credential will fail as soon as you use one of those actions, even if the dashboard views themselves load fine.

Integrations

Tailscale

• Config fields: Tailnet, API key
• Auth: Bearer token against api.tailscale.com
• Actions used: list devices, remove a device, authorize/deauthorize a device
• Required access: An API access token (or OAuth client) with Devices Core: Read + Write — create one under the admin console → Settings → Keys. Read-only isn't enough since remove/authorize are write calls.

Proxmox VE

• Config fields: Proxmox URL, API token ID, API token secret, allow self-signed certificate
• Auth: PVEAPIToken=<tokenId>=<tokenSecret> header
• Actions used: list nodes/VMs/LXCs, read guest config and live status, read node host stats and storage usage, start/stop/reboot/shutdown a guest, read backup job schedules and recent vzdump task history
• Required access: A dedicated API token (Datacenter → Permissions → API Tokens) with a role granting VM.Audit + VM.PowerMgmt (e.g. PVEVMAdmin) on the VMs/LXCs to manage, plus Sys.Audit and Datastore.Audit on the node(s) for the host CPU/RAM/storage cards to populate. A token scoped to VM management only will still work for the guest list and power actions — it'll just show an error on the per-node hardware card instead of failing outright. Backup job schedules and run history need that same Sys.Audit — no separate permission to grant if the node-stats card already works.
• Notes: self-signed certificates are supported via the "Allow self-signed certificate" checkbox — common for an internal PVE host.

Synology DSM

• Config fields: Synology DSM URL, Username, Password, allow self-signed certificate
• Auth: DSM session login (SYNO.API.Auth), session id reused until it expires
• Actions used: read-only — storage/volume/disk health, system info, network info. No writes.
• Required access: A DSM user account that can view Storage Manager and System Information (a regular admin-group account is simplest; a dedicated read-only user works too since nothing is ever changed). 2FA/OTP on the account is not supported — use an account without it enabled, or DSM's application-specific password if your setup requires 2FA elsewhere.
• Notes: works over plain HTTP or HTTPS depending on the URL you enter; self-signed certs supported.

Semaphore (Ansible Semaphore / Semaphore UI)

• Config fields: Semaphore URL, API token
• Auth: Bearer token
• Actions used: list projects, list templates, run a template (creates a task)
• Required access: A user API token with access to every project you want visible, and permission to run templates in those projects — a viewer/guest-level project role can list templates but will fail on "Run", so the account needs at least the operator-equivalent role Semaphore's own project permissions define.

Gitea

• Config fields: Gitea URL, API token
• Auth: Authorization: token <token> header
• Actions used: list repos, list Actions workflow runs, re-run failed jobs in a run
• Required access: A personal access token with repo scope (read access to repos, including private ones you want tracked) and Actions read/write — generate it under the account → Settings → Applications → Generate New Token, with the repository and write:repository/Actions permission groups enabled (exact grouping depends on your Gitea version's token scope UI). Read-only Actions access isn't enough since re-running jobs is a write call.

Dockhand

• Config fields: Dockhand URL, API token
• Auth: Bearer token against Dockhand's own API
• Actions used: list environments/containers, check for image updates, start/stop/restart a container
• Required access: A Dockhand API token belonging to a user with access to every environment (Docker host) you want visible, with permission to start/stop/restart containers and trigger update checks in each — not just view them.

Uptime Kuma

• Config fields: Uptime Kuma URL, username (leave blank — see below), API key
• Auth: HTTP Basic, with the API key as the password and the username left empty. Uptime Kuma has no conventional REST API — the dashboard talks to it over Socket.IO — so this integration reads its Prometheus-metrics endpoint (GET /metrics) instead and parses that. On installs from before the API-key feature existed (Uptime Kuma < 1.23), that endpoint instead checks your real dashboard login, so put your Uptime Kuma username and password in those two fields rather than leaving the username blank.
• Required access: In Uptime Kuma, go to Settings → API Keys → Add API Key, and paste the value it shows you (once — it isn't shown again) into this integration's "API key" field. No other permission is needed; the metrics endpoint is read-only.
• What you get: every monitor's status (up/down/pending/maintenance), response time, uptime over 24 hours/30 days, and certificate days remaining where applicable. A monitor is linked to one of your servers when its target — an IP, or a TCP/HTTP hostname — matches that server's own address or hostname; monitors with no single network target (groups, push monitors, keyword checks with a complex URL) are shown unmatched rather than guessed at. Uptime Kuma's tags aren't read, since the metrics endpoint doesn't reliably distinguish a tag from any other label.
• Maintenance import: the Maintenance page can read which monitors are currently in maintenance in Uptime Kuma and start (or extend) a maintenance window here for the matching server, for a duration you pick — the metrics endpoint only exposes current status, not a monitor's scheduled start/end time, so this reflects what's in maintenance right now rather than mirroring Uptime Kuma's own schedule.

phpIPAM

• Config fields: phpIPAM URL, API app ID, App token
• Auth: the token header (and phpipam-token, in case your version expects that name instead), set to a static per-app code. In phpIPAM, go to Administration → API, create (or edit) an API app, and set its App security to "SSL with App token" (or "App token" if the install isn't served over HTTPS). Saving it shows the app's code once — that's what goes in this integration's "App token" field, and the app's own short id (chosen when you created it) goes in "API app ID". phpIPAM's other auth method — logging in as a real user to get a short-lived token — isn't supported; use an App-token app instead.
• Required access: the API app just needs read access to whichever sections/subnets you want imported.
• What it does: this is import-only, not a full integration page — on the IP Addresses page, "Sync from phpIPAM" reads every subnet and the addresses in each, and adds or updates an IPAM entry per address (label from its hostname or description, the subnet's own description as its location, description/note/MAC folded into notes), the same way "Sync from Tailscale"/"Sync from Proxmox" already work: an address you entered by hand, or that a different sync source owns, is never overwritten.
• Not verified against a live instance — built from phpIPAM's own published API documentation (endpoints, the token header, and the address/subnet field names all cross-checked there), but nobody has run it against a real phpIPAM yet. If a sync comes back empty or with the wrong fields, tell us what your instance actually returned and we'll adjust.

DNS providers

Cloudflare

• Config fields: API Token
• Auth: Bearer token against the Cloudflare v4 API
• Actions used: list zones, list/create/update/delete DNS records
• Required access: A scoped API token (My Profile → API Tokens → Create Token) with Zone → Zone → Read and Zone → DNS → Edit, restricted to the zone(s) you want managed. DNS Read alone isn't enough — record add/update/delete need Edit.

Loopia

• Config fields: Username, Password
• Auth: Full account credentials sent on every XML-RPC call — Loopia's API has no scoped API-key concept
• Actions used: list domains/subdomains/zone records, add/remove zone records and subdomains
• Required access: The full Loopia account username and password. There's no way to scope this down at the API level — the credential has the same access as logging into the Loopia customer portal.

Pi-hole

• Config fields: Pi-hole URL, Web password
• Auth: Session login against the Pi-hole v6 API (/api/auth) using the admin web password, session id cached until it expires
• Actions used: read/add/update/delete local DNS "hosts" (A/AAAA) and CNAME records
• Required access: The Pi-hole admin web interface password — Pi-hole v6 doesn't have per-feature roles, so this is effectively full admin access to that Pi-hole instance.

Azure DNS

• Config fields: Tenant ID, Client (application) ID, Client secret, Subscription ID
• Auth: OAuth2 client-credentials (Azure AD app registration / service principal), then Bearer token against Azure Resource Manager
• Actions used: list DNS zones, list/read/create/update/delete record sets
• Required access: The service principal needs the DNS Zone Contributor role (or higher) on the subscription or resource group containing the DNS zone(s) — assign it under Azure Portal → the zone or resource group → Access control (IAM) → Add role assignment.

cPanel

• Config fields: cPanel URL, Username, API Token, allow self-signed certificate
• Auth: Authorization: cpanel <username>:<apiToken> header (UAPI for reads, API 2 for record writes)
• Actions used: list zones/domains, read a zone's records, add/remove a zone record
• Required access: An API token generated under cPanel → Security → Manage API Tokens for the account that owns the domain(s) being managed. cPanel tokens inherit the full account's permissions — there's no separate DNS-only scope to grant.

Technitium DNS Server

• Config fields: Technitium URL, API Token
• Auth: Bearer token
• Actions used: list zones, read zone records, add/delete records (an "update" is implemented as delete + add)
• Required access: A token tied to a Technitium user account with Zones: View + Modify permission — view-only will fail on record changes since updates are add/delete calls under the hood.