Secure a Buttons deployment

Start here: how exposed is this deployment?#

• Local-only (a single machine, no network exposure beyond localhost): the lightest baseline. Strong accounts and a good backup plan still matter, but network-facing hardening is less urgent.
• LAN (reachable from a studio or building network, not the public internet): add real TLS and locked-down account access, since anyone on that network is a potential reader or attacker if a account is weak or a certificate is skipped.
• Externally managed (behind a load balancer, reverse proxy, or Kubernetes ingress, or otherwise reachable beyond your own network): treat certificates, API keys, and account access as if a stranger will eventually try them, because eventually one will.

Accounts and access#

1. Give every person their own user account rather than sharing credentials. See Create and manage users.
2. Build roles around what each job actually needs, not blanket access. See Create roles and assign permissions.
3. If you're running a multi-node deployment or need to see who's actively signed in, review Understand and manage sessions: note this page is off by default and may not be enabled for your deployment.
4. For surface-based sign-in, PIN and NFC are convenient but should still be treated as credentials. See Set up PIN and NFC sign-in. Repeated wrong passwords, PINs, or LDAP credentials on the same account are throttled automatically: after a few free wrong attempts (5 for passwords and LDAP, 3 for PINs), each further wrong attempt doubles the wait before the next check, starting at one second and capped at 2 minutes. A correct attempt clears the history. This needs no configuration, and because the wait never exceeds 2 minutes, someone typing wrong passwords can't lock the real owner out of their account.
5. Protect the System Administrator account specifically: it can't be deleted, and if its password is lost, recovery goes through the watchdog application on the host machine, not the web interface (covered in Create and manage users).
6. Bind connection credentials to a secret rather than leaving them as plain configuration text, and know that deleting a secret isn't blocked even while something still depends on it. See Store and rotate connection secrets.
7. If you're connecting an enterprise identity provider, bring it online in the safe order: verify it with a real sign-in before switching anyone over to it by default. See Get started with SSO. Local sign-in is never disabled by SSO configuration, but keep a working local administrator account available regardless.

Network and transport#

1. Know exactly which ports need to be reachable, from where, before you open anything. See the Network ports reference. Widening the editor's listen address beyond localhost is a deliberate choice, not a default.
2. Replace the automatically generated self-signed certificate with one from a trusted authority once you're reachable beyond localhost. See Replace the HTTPS certificate. Plan the certificate's hostname coverage before you're mid-incident and need it to already be right.
3. If Buttons runs behind Kubernetes or another externally managed certificate system, confirm that system (not this page) is what's actually renewing and rotating the certificate.
4. For remote-execution connections like Bitfocus Listener, keep the credential hidden with a secret binding and scope which actions the remote side will actually run. See Connect to Bitfocus Listener.

API access#

1. Confirm which interface an integration should actually use. See Choose how another system operates Buttons.
2. Give every integration its own scoped key rather than a shared one, and grant only the permissions it actually uses. See Get started with the Control API.
3. Set a rate limit appropriate to your real traffic, and monitor the request log for anything unexpected. See Secure and monitor the Control API.
4. Revoke a key immediately if you suspect it's been exposed: revocation is immediate and can't be undone, which is the point.

Backups and recovery#

1. Set up at least one scheduled backup rule so a recent, working configuration always exists. See Configure and monitor scheduled backups.
2. Know how to export or import configuration manually for one-off moves, and understand exactly what an export does and doesn't protect. See Export or import Buttons configuration.
3. Know the actual restore path and its automatic-rollback guarantee before you need it under pressure. See Restore and verify a backup.
4. Treat every exported archive as sensitive: it can include connection configuration and license data even when secrets are excluded.

Ongoing health#

If you get stuck#

Where to go next#

• Settings overview, for the full list of Settings pages this guide draws from.