Mighty Seventh District, Omega Psi Phi Fraternity, Inc. A modern platform for the Mighty Seventh — production-grade, District-owned,...

Overview

The Mighty Seventh District of Omega Psi Phi Fraternity, Inc. is the regional body that covers Alabama, Florida, Georgia, and Mississippi — 147 active chapters, the 26th District Representative in Bro. James M. Reed IV, and the institutional weight of the fraternity's continuous service since 1928.

For most of the last decade, the District's web presence was carried on a DotNetNuke platform that served the brotherhood for many years. As the District's work grew — new programs, new chapters, a richer editorial calendar, a clearer integration story with the 7D system of record — the leadership team felt it was time to bring the platform forward to match.

That's the engagement Kanonu Solutions was asked to lead, in partnership with the District's leadership and webmaster team.

The new site is live at oppf7d.org.

The challenge

Four themes shaped the work from the first conversation:

• A platform built for a different era. The previous DotNetNuke deployment served the District well in its time, and we owe the brothers who stood it up genuine respect for that. But the editorial pace of a 147-chapter District in 2026 — new programs, new partnerships, a meeting and event cadence that wants live updates — had outgrown what that platform was designed to support. Officers were doing more and more work outside the site because it was easier than working inside it.
• A 7D system of record that should be the source of truth. Bro. Devine, the District's Webmaster, maintains the authoritative database for members, chapters, and officers — and a 7D API to surface that data cleanly. The new platform had to be designed so roster information flows from that system of record over time, without duplicating its data and without forcing the API to exist before day one.
• Content authority belongs with the people producing the content. When the editorial calendar called for a Health & Wellness article or a photo gallery from a District meeting, the publishing path involved an engineer. The new platform needed an authoring surface that District leadership could use directly, so brothers writing the content could publish the content.
• An infrastructure story worth documenting. Continuous integration, environment separation, reproducible deploys, a clear handoff path between webmasters — these are the kinds of things that quietly make the difference between a platform a successor can pick up confidently and one they can't. Bringing those up to current practice was part of the scope.

The work the District has done since 1928 is real. The platform underneath it had room to grow with it.

Our approach

We treated this as a platform engineering engagement scoped in partnership with the District's webmaster team. Three commitments shaped the work:

1. District ownership, end to end. Every line of code, every Terraform file, every CI workflow lives in the District's own GitHub organization. The same is true of the Azure subscriptions — production and test are separate, both owned by the District. When the gavel passes to the next Webmaster, they inherit a system they can read, learn, and extend.
2. The 7D system of record stays the source of truth. The application is a Backend-for-Frontend (BFF) that ships with embedded seed data for day one, and accepts per-collection overrides so any individual collection — members, chapters, officers — can be pointed at the 7D API as that API comes online. Roster data flows from the system of record over time. Editorial content stays site-owned. No duplication.
3. Content authors edit content. Engineers edit code. District leadership manages Articles and photo Galleries directly from a Brother Portal admin section. Site editorial content (events, partners, featured story) lives in version-controlled data files that officers can edit on GitHub using the content cookbook. The publishing path doesn't pass through engineering.

What we shipped

A complete platform, in production at oppf7d.org, brought online in June 2026.

• Brand system anchored in the fraternity's royal purple and old gold, with a chapter-rollout style sheet, a 7th District logo system, and a typographic pair of Fraunces (display) and Inter (sans). The visual identity scales from a 32×32 favicon to a 4K presentation deck without translation.

• Public website at oppf7d.org — a single-page experience covering the District Representative's message ("The Path Forward"), the Office of the DR, History, the District Council and officers, Undergraduates, Resources, Events, Stories, and a universal search across brothers, committees, chapters, and programs. Member-facing payment flows for District Dues and MSP Fees. Gated registration for the 26th District Meeting.

• A bespoke Go application — the BFF. The application embeds the static site and the District's seed data into a single Linux container, serves the District's read-only data at /api/public/*, and runs anywhere a container can run. Single binary. No Node. No PHP. Predictable runtime.

• Brother Portal authentication. Member sign-in via sealed-cookie session (AES-256-GCM, HttpOnly + Secure + SameSite=Lax). Two admin tiers — super_admin (content + admin management) and site_admin (content only). First admins are seeded automatically at deploy time, so leadership onboarding doesn't require database access.

• An admin content management system inside the Brother Portal. District leadership manages Articles (taxonomy: health, district-news, and a section per statewide org) and photo Galleries directly from the portal. Metadata lives in TursoDB; uploaded media (hi-res images, PDFs) flows to Azure Blob Storage via short-lived SAS URLs the BFF mints. The server hands clients direct, scoped URLs rather than proxying media itself.

• Azure cloud infrastructure, fully codified.

  • Linux App Service for Containers running the distroless Go image.
  • Azure Container Registry for the image registry.
  • Azure DNS for oppf7d.org, no third-party proxy.
  • App Service Managed Certificate — free, auto-renewed TLS.
  • Azure Blob Storage for admin media (auto-provisioned by Terraform).
  • TursoDB for admin-managed content metadata, with a SQLite fallback for local development.

• A production CI/CD pipeline on CircleCI with separate workflows for application changes, infrastructure changes (Terraform plan → manual approve → apply → deploy), and branch-level safety checks (Go vet, tests). A mirrored test environment lets any branch be exercised end-to-end before merge to main.

• OIDC-federated CI authentication. Zero long-lived Azure secrets in CircleCI. Each deployer's federated credential is declared as a tracked Terraform variable. Adding or removing a deployer is a short pull request. The audit trail is the git history.

• A 12-Factor configuration model that lets the same Docker image run anywhere with only environment variables changing. The central knob is which store provider backs each collection — so a test environment can stand up on the embedded seed with zero real backing services, and production can opt individual collections onto live backings as those backings come online.

• A security posture worth listing in full: distroless nonroot container, static Go binary, https_only=true on the App Service, AES-256-GCM-sealed session cookies, parameterised SQL queries everywhere, uploads routed through short-lived SAS URLs, request body size limits on login and admin JSON endpoints, OIDC federation for CI, and separate Azure subscriptions for production and test.

• A full security audit (June 2026) with tracked remediation items at multiple severity levels, prioritised against the District's editorial calendar.

The outcome

Inside the first 30 days after the new platform came online:

• The District owns its platform end to end. Repository, infrastructure, deploy pipeline, certificate, DNS — all in District-controlled accounts and in the hands of the brothers who maintain them.
• Officers can publish without an engineer in the loop. Articles and galleries through the Brother Portal CMS. Site editorial through the content cookbook.
• The path to the 7D API is clear and incremental. When members, chapters, and officers move to the 7D system of record, three environment variables flip one collection at a time. No re-architecture.
• Every deploy is reproducible. Same Docker image in test and production, same Terraform plan, same OIDC trust. A new webmaster comes up to speed in an afternoon.
• TLS, DNS, certificates, and backups run themselves. Azure manages the certificate. Terraform manages the infrastructure. CircleCI manages the deploys. The District's energy goes to writing Articles and serving the brotherhood.
• The 26th District Meeting registration flow is live, on the same platform, behind the same authentication, with no separate vendor.

The District's work for the brotherhood and the four states it serves is real. The platform underneath it now matches the pace.

A note on what's next

Tracked next-up items, in order of priority:

• Security headers middleware (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
• Rate limiting on the authentication endpoint and HTML sanitization on admin-authored content.
• The 7D API provider implementation, so members, chapters, and officers flow from the District's system of record.
• Migration of the embedded seed galleries into Turso, once the admin CMS is ready to be the primary gallery editing surface.
• Routing the health content into the health library and per-state placement for the statewide-org articles.

Maintainers, listed in the README:

• Bro. Devine — District Webmaster
• Bro. Will Madison — Co-Webmaster
• Bro. Enebeli Kanonu — Co-Webmaster

Three brothers serving the District together. That's the shape this platform was built to live inside.

If you're a regional body, fraternal organization, or community institution carrying important work on a platform that wants to come forward, start a project — engagements scoped in partnership with their owners are the shape we run best.