Admin Go-Live Checklist

Use this checklist before an Agility instance goes into production. It covers what an Agility admin owns: sign-in, people and roles, keys and tokens, webhooks, preview, redirects, AI access, monitoring and recovery. Your developers will also work through the Website Deployment Checklist for the site itself.

Each item links to the article with the steps. Items marked with a plan name need that plan.

For who is responsible for what, see The Agility Shared Responsibility Model.

1. Sign-in and authentication

• Decide which sign-in methods to allow for your organization: email and password, Google, Microsoft, GitHub, or Enterprise SSO. Restricting sign-in methods needs a Pro or Enterprise plan. To change these settings, contact support@agilitycms.com; they aren't available in the Content Manager yet. See User Authentication.
• Set up Enterprise SSO if you use it (Enterprise plan). Contact your customer success representative or support@agilitycms.com. SAML setup needs your identity provider's sign-in URL, sign-out URL, signing certificate and the email domains the connection applies to. See Enterprise Single Sign-On with Agility and SAML Identity Provider Integration.
• Enforce MFA (Pro or Enterprise plan) by contacting support@agilitycms.com. MFA enforcement applies to email and password sign-in across the organization. Ask for the Google, Microsoft and GitHub sign-ins to be turned off too, otherwise users can skip MFA by signing in with a social account. If you use SSO, enforce MFA at your identity provider. See Multi-Factor Authentication.
• Tell Microsoft Entra users to sign in with their UPN. With the Sign in with Microsoft button, Agility accepts only the UPN email address, so each person's Agility email address must be their UPN. See Authenticate with Microsoft or Azure AD/Entra.
• Share the direct SSO sign-in link (https://manager.agilitycms.com/login?connection=<connection-name>) on your intranet so people go straight to your identity provider. Agility gives you the connection name when it sets up your connection.
• Remind people to store their MFA recovery code somewhere safe.

2. Organization admins

• Review who your Organization Admins are. They can create instances and manage subscriptions and billing. To add or remove one, contact support@agilitycms.com. See Organization FAQ's.
• Remember that Organization Admin does not grant instance access. Instance access is managed separately, in each instance.

3. People, roles and workflow

• Give each person the lowest role that works. Compare roles in the Roles and Permissions Matrix, and use Role Design Recipes for agencies, contractors and reviewers.
• Remove build-time access. Delete test users, and reduce the roles of developers and agency staff who no longer need Admin or Manager in production, in Settings > User Access. See User Access.
• Use Teams for groups of people (Enterprise), and don't also grant the same people individual access: individual access overrides team access. See Teams.
• Use item-level permissions to raise access where needed. They only add to the instance role; they cannot lower it. See Item-level Permissions.
• Decide who can publish and delete. Turn on Requires Approval for pages and Enable Approval Workflow for content lists where a person should sign off. See Approvals and Workflows.
• Run the Permissions report under Reports and keep a copy as your go-live access baseline. See Roles and Permissions Matrix and User Lifecycle at Scale.

4. API keys

• Use the right key in each place. The Fetch key reads published content. The Preview key also reads draft content and belongs on the server only. The Security Key validates the preview key and must stay server-side. See API Key Management.
• Keep keys out of code and out of the browser. Store them in environment variables or a secrets manager, and keep Preview and Management credentials out of client-side code. See Hosting, Security & Compliance.
• Use separate keys for separate environments and applications, where you can.
• Regenerate any key that was shared widely during the build in Settings > API Keys, then update every application and environment that uses it.

5. Personal Access Tokens

• Create automation tokens under a dedicated automation user, not a person. A token inherits the permissions of the user who creates it. See Personal Access Tokens.
• Set an explicit expiry date. The maximum is two years.
• Store tokens in a secrets manager and rotate them.
• Revoke tokens created during the build that production does not need.

6. Webhooks

• Turn on secure delivery for every webhook, and verify the signature on every request using the raw request body. See Verifying Signed Webhooks.
• Store the signing secret with your endpoint's configuration. Viewing or rolling it needs Full Control.
• Know how to roll the secret. After a roll, Agility signs with both the new and previous secret for 24 hours.
• Point each webhook at its final URL. Redirects count as failures, and the delivery timeout is 30 seconds, so acknowledge quickly and do slow work afterwards.
• Turn on retries where a missed event matters, and make your endpoint idempotent using the webhook-id header.
• Verify signatures rather than filtering by IP address. Agility doesn't publish a list of webhook source addresses, and they can change. See Audit Trail, Logging & SIEM Integration.
• Check delivery History in Settings > Webhooks after your first publishes.

The instance Security Key under Settings > API Keys is for preview, not webhooks; see Webhook Events and Payload Reference.

7. Preview and Web Studio

• Confirm preview works on the production setup. Editors need it once the site is live. See Setting Up Preview.
• Keep the Preview key and Security Key server-side. In the Next.js starter, AGILITY_SECURITY_KEY must match the Security Key in Agility for preview to work. See Preview URL Lifecycle.
• Allow Web Studio to frame your site if you use it: your Content-Security-Policy frame-ancestors must include https://app.agilitycms.com. See Troubleshooting Web Studio.

8. Redirects

• Import your redirect map from the old site in URL Redirections, using 301 for permanent moves and 302 for temporary ones. See URL Redirections.
• Test your redirects before launch with the Test action in URL Redirections, and ask a developer to look at any that fail. See Testing URL Redirections.
• Export a copy of the redirect list for your records.

9. AI access

• Decide your AI policy before launch: which AI clients are allowed, which roles can publish or delete through AI, and the level of autonomy for each kind of content. See Governing AI Access to Agility CMS.
• Review what data leaves Agility when people use AI. See What Happens to Your Data When You Use AI.
• For Microsoft 365 Copilot, require end-user authentication and check your DLP policy. See Connect the Agility MCP Server to Microsoft 365 Copilot.

10. Network access

• Plan network restrictions through your identity provider. Agility doesn't offer IP allowlisting. To limit sign-ins to your network or devices, make SSO the only way in and apply your identity provider's policies, such as Microsoft Entra Conditional Access. See Security Review Guide.

11. Logging and monitoring

• Subscribe to incident notifications at status.agilitycms.com.
• Forward publish, unpublish and delete events to your log store or SIEM if you need them, with a webhook handler. There is no native SIEM connector. See Audit Trail, Logging & SIEM Integration.
• Capture sign-in events in your identity provider. Agility does not offer a customer-facing log of users added or removed, role changes or token creation today.
• Turn on your hosting platform's observability for the live site and its calls to Agility.

12. Data region, backups and recovery

• Confirm the instance's data region meets your residency requirements. Moving region later needs planning and a statement of work. See Data Residency & Data Regions.
• Know what Agility backs up. Agility backs up content automatically and can restore an instance to a recent point in time. Recovery objectives and backup retention are available on request. See Disaster Recovery & Business Continuity.
• Show editors how to restore a previous version of a content item or page. Restored versions come back in Staging. See Version History and Commenting.
• Write down your internal process for requesting a platform restore, including who contacts Agility support. Ask your account team or support@agilitycms.com how restores are requested and what they cover.
• Plan continuity for your own front end and hosting. That part is yours.
• Keep your own export if your policies need one. The Agility CLI can pull an instance's content and structure to local files. See Getting Your Content Out: Data Portability and Exit.

13. Contacts

• Record where to report a security issue: support@agilitycms.com, as described on the Agility security page.
• Record your Agility support and customer success contacts in your runbook. For a security setting this checklist doesn't cover, such as session timeouts, ask them.

Related articles

• The Agility Shared Responsibility Model
• Security Review Guide
• User Lifecycle at Scale
• Security Review Pack
• Website Deployment Checklist
• Hosting, Security & Compliance