Wagtail多站点权限分组及实例部署方案技术咨询

Hey Will, great to hear you're leaning into Wagtail—it's absolutely the right tool for this multi-site setup, and you won’t need to deploy multiple instances. Let’s walk through how to meet all your requirements, plus share some real-world best practices for large multi-site Wagtail projects:

First off, you can absolutely run all 7 sites (1 main + 6 subdomain) on a single Wagtail instance. Wagtail’s native multi-site support is built for exactly this use case: each site gets its own domain/subdomain, shared codebase, and database, but operates as a separate entity in the admin. This keeps maintenance overhead way lower than managing 7 separate instances, and makes cross-site operations (like Staff(A) publishing to multiple sites) seamless.

Wagtail’s permission system is flexible enough to handle your group structure out of the box, with a few key configurations:

1. Primary Group Configuration #

• Create your two top-level groups: Staff (A) and Contractors
  • For Staff (A): Assign global admin access plus full Add, Edit, and Publish permissions for all 7 sites. When editing content, Wagtail’s native interface lets users choose which site(s) to publish to—so Staff(A) can easily select the main site, all 7 sites, or any subset directly from the page editor. No custom code needed here.

2. Contractor Subgroups & Site-Specific Isolation #

• Under Contractors, create 6 child groups (e.g., Contractor - Site 1, Contractor - Site 6)
  • For each subgroup, only assign Add, Edit, and Publish permissions for their specific site. Do NOT grant any global or cross-site permissions.
  • This automatically restricts users in these subgroups to only see and edit content belonging to their assigned site—including content created by Staff (A) for that site. They won’t have access to content from other sites, even if it was created by a parent group.

3. Cross-Site Roles (Partial Site Access) #

Your ideal requirement of letting some roles access multiple (but not all) sites is fully supported natively. Just create a dedicated group (e.g., Contractor - Sites 1 & 2) and assign permissions for each of the relevant sites. Users in this group will only see content from those sites in the admin—no extra work needed.

You mentioned worrying about restricting access to content created by parent groups. This is automatically handled by site-specific permissions:

• If Staff (A) creates content for Site 1, only users with Site 1 permissions (Staff(A) and Contractor - Site 1) can view or edit it.
• For shared content like snippets or images, you can either:
  • Assign snippet-specific permissions to restrict access per group, or
  • Extend snippet models with a site foreign key, then use Wagtail’s permission filters to only show snippets associated with a user’s allowed sites (this requires a small amount of custom code, but is straightforward).

From working on enterprise-scale Wagtail multi-site projects, here are a few tips to keep things smooth:

• Site-Specific Page Models: Create unique page types for each site (e.g., Site1HomePage, Site2BlogPage). This makes permissions easier to manage and prevents cross-site content confusion.
• Custom Permission Filters (If Needed): For edge cases, you can override Wagtail’s admin views to add custom filters based on user groups, but 90% of the time native permissions are sufficient.
• Site-Specific Caching: Configure your cache to include the site ID in cache keys to avoid mixing up content between sites.
• Audit Logging: Enable Wagtail’s built-in audit logs to track user actions across sites—critical for compliance and troubleshooting.
• Test Rigorously: Use test accounts for each group to verify permissions are working as expected. It’s easy to miss a permission setting, so thorough testing is key.

Hope this clears things up—Wagtail is more than capable of handling this setup, and the single instance approach is definitely the way to go.

内容的提问来源于stack exchange，提问作者Will