Managed Cloud & Security
BlackWolf for Montana – Campaign Website
The official campaign website for Michael Black Wolf for U.S. Senate The project included a custom Next.js website with a Sanity CMS, issues and updates management, secure hosting, Google Workspace integration, and a scalable foundation to support an active political campaign.
Before and after
The situation
The challenge
The campaign had to stand up a complete public-facing platform and a staff collaboration environment from zero, on a compressed timeline, while already operating. There was no existing cloud footprint, no identity model, no operational ownership of DNS, and no authenticated email for the domain.
Three problems sat underneath the obvious one:
- An unowned domain and email perimeter. The campaign domain had no sender authentication and no registrar-level protections. For an organization that solicits donations and press contact by email, spoofing and impersonation are a direct financial and reputational risk, not a theoretical one.
- No separation between content changes and production deployments. Every messaging change would have required a developer and a full release cycle. In a campaign news cycle measured in hours, that coupling is an operational failure mode.
- Unpredictable, event-driven load. Traffic for a political campaign arrives in spikes tied to news coverage, debates, and announcements. A conventional origin-server setup would either sit overprovisioned and expensive most of the time, or fall over exactly when visibility peaked.
The engagement was therefore scoped as an infrastructure and security problem first, and a content platform second.
Supported outcomes
Results and project impact
Outcomes are stated as delivered capability rather than projected metrics.
- The campaign was operating on secure infrastructure before the public platform launched. Identity, authenticated email, and collaboration tooling were live in the first delivery phase, so outreach began immediately rather than waiting on the site.
- The domain perimeter is verifiable. With SPF, DKIM, and DMARC in place and registrar locking enabled, campaign email is authenticated at receiving servers and spoofed mail can be rejected rather than merely suspected.
- Messaging is fully owned by the campaign. Staff publish policy positions, news, and homepage content directly, with no developer in the path and no deployment required. The change-control step is built into the workflow rather than depending on discipline.
- Capacity is no longer a planning problem. Edge delivery and scale-to-zero rendering mean traffic spikes are absorbed automatically, with no overprovisioned infrastructure sitting idle between them.
- Run-rate cost is variable and low. With no fixed server spend, no separate CDN, firewall, or backup contracts, and no recurring patch labor, the floor cost of keeping the platform live is minimal.
- Recovery is fast and bounded. Immutable deployments make rollback a single step, and monitoring surfaces the most probable failures — expiry, build failure, sustained downtime — before users encounter them.
- The environment is documented and transferable. The campaign holds an access matrix, DNS inventory, and runbook, and is not dependent on a single individual's memory.
The broader point: a campaign site is an infrastructure and trust problem before it is a content problem, and treating it that way early is what makes the later stages uneventful.
Recommended approachStrategy
The guiding decision was to own as little infrastructure as possible and secure everything that remained.
Managed and serverless first. Every component the campaign would otherwise have to patch, back up, or monitor was pushed onto a managed platform. No virtual machines, no operating systems, no database servers, and therefore no patch backlog and no 3 a.m. pager for a volunteer.
Infrastructure before application. Identity, email, and DNS were delivered as the first phase so the campaign could operate immediately while the public platform was still being built. This also meant the domain perimeter was hardened before the site ever drew attention.
Least privilege from day one. Access was scoped per role at the point of provisioning rather than retrofitted later, which is the only reliably cheap moment to do it.
Change control through the content model, not through process. Rather than asking staff to follow a publishing policy, we encoded the constraint structurally: content lives in typed, validated documents with a draft state, so the safe path is also the default path.
Consumption-based economics. Both the delivery tier and the content backend bill on use. A quiet week costs almost nothing, and a viral week scales without an architecture change or a procurement conversation.
How the work movedDelivery process
The engagement ran in six phases, sequenced so the campaign gained operational capability at the earliest possible point rather than at the end.
1. Discovery and risk assessment. Inventory of the existing domain, mail, and DNS position; identification of the impersonation, availability, and access risks; agreement on scope and what would deliberately stay out of scope.
2. Infrastructure foundation. Google Workspace provisioning, named accounts, two-factor enforcement, DNS consolidation, and email authentication. Delivered first, which put staff into secure operation while the platform build was still underway.
3. Content architecture and platform build. Content modeling, schema validation rules, application development, and pipeline configuration with per-change preview environments.
4. Hardening and performance engineering. Security header and TLS enforcement, access scoping review, caching and revalidation tuning, image and rendering optimization.
5. Cutover. Staged DNS change with reduced TTLs, mail flow verification, and post-cutover validation of certificates, redirects, and authentication records.
6. Handoff and knowledge transfer. Documentation delivery, live training session, and transition into the ongoing support arrangement.
Each phase closed with a review against the goals agreed in phase one, so scope changes were explicit rather than absorbed.
After launchCurrent status and ongoing support
The platform is live and under active managed support.
Day to day, the campaign operates independently — staff publish content, manage their own accounts within Workspace, and require no technical assistance for routine work. Our involvement is deliberately limited to the layers that need expert attention: patching, access hygiene, DNS and certificate lifecycle, monitoring, and incident response.
We review the environment on a recurring cadence covering dependency updates, access lists, DMARC reports, and actual consumption against cost. Findings go to the campaign as short, plain-language summaries with a recommendation rather than a report to interpret.
As the race progresses and traffic patterns shift, the architecture scales without redesign. The next natural extensions — additional integrations, expanded content types, or tighter analytics — can be scoped incrementally without disturbing the foundation already in place.
Context
Client or organization background
Michael Black Wolf is a candidate for U.S. Senate representing Montana. His campaign needed a professional digital platform to communicate values, policy positions, and calls to action — while remaining flexible enough for campaign staff to manage without developer support.
Success criteria
Project goals
- Stand up secure cloud and collaboration infrastructure ahead of the public platform
- Harden DNS and establish verified email authentication for the campaign domain
- Remove developer dependency from day-to-day content operations
- Absorb unpredictable traffic spikes without capacity planning or overprovisioning
- Enforce least-privilege access across hosting, CMS, and email
- Keep run-rate infrastructure cost low and predictable with no fixed server spend
- Hand over a documented environment the campaign can operate and audit independently
InnoNative responsibilities
Scope and services delivered
- Cloud Infrastructure Design
- DNS Architecture & Hardening
- Email Security (SPF/DKIM/DMARC)
- Identity & Access Management
- Cloud Modernization
- Edge Performance Engineering
- CI/CD Pipeline Implementation
- Security Posture Assessment
- Monitoring & Alerting
- Cloud Cost Optimization
- Documentation & Knowledge Transfer
- Managed Support Retainer
Implementation
Technical solution
Delivery was executed in two tracks so the campaign could begin operating before the public platform shipped.
Infrastructure track. Google Workspace was provisioned as the identity and mail foundation, with named accounts, enforced two-factor authentication, and shared Drive and Calendar resources for staff coordination. DNS was consolidated and rewritten with a documented record set, then hardened with SPF, DKIM, and DMARC alignment and registrar locking. This track was delivered first and put the campaign into operation within days.
Platform track. A server-rendered Next.js application was built against the Sanity Content Lake API. Content is modeled as typed documents — policy issues, news and updates, and homepage messaging — each with validation rules and its own routed page. The model deliberately prevents the two most common failure modes in campaign sites: duplicated messaging that drifts out of sync, and layout breakage caused by free-form editing.
Delivery and caching. Static generation covers stable pages, incremental revalidation handles content that changes during the day, and the edge cache absorbs the rest. Image assets are transformed and served in modern formats at request-appropriate sizes from the same edge network.
Pipeline. Deployments are Git-triggered, with preview environments generated per change and production promotion as an explicit step. Rollback is instantaneous because prior builds remain immutable and addressable.
The net effect is a system where the campaign controls messaging entirely, and controls infrastructure not at all — by design.
Capabilities
Key features
- Role-scoped publishing with no infrastructure access required
- Draft and preview workflow as an enforced change-control step
- Structured content model with per-topic routed pages
- Automated TLS provisioning and renewal
- Git-based deployments with immutable, instant rollback
- Globally edge-cached delivery with incremental revalidation
- Centralized staff identity with enforced two-factor authentication
- Authenticated campaign email with SPF, DKIM, and DMARC
- Automatic image optimization at the edge
- Server-rendered pages for crawler and low-bandwidth performance
Connected systems
Integrations
- Google Workspace (identity and mail)
- Google Drive
- Google Calendar
- Sanity Content Lake API
- Vercel deployment pipeline
- Git-based source control
- Authoritative DNS and registrar
Handoff
Launch deliverables
- Production cloud environment at blackwolfformontana.com
- Hardened DNS configuration with documented authoritative record set
- Email authentication suite (SPF, DKIM, DMARC) with verified mail flow
- Google Workspace tenant with named accounts and enforced two-factor authentication
- Structured content platform with role-scoped editorial permissions
- Git-based CI/CD pipeline with preview environments and instant rollback
- Edge caching and performance configuration
- Monitoring and alerting configuration
- Access matrix and offboarding procedure
- DNS record inventory and operations runbook
- Editor guide and recorded knowledge-transfer session
- Security posture summary and recommendations
Visual details
Project gallery
Selected screens and project materials. Open any image for a larger view.
Your next step
Have a project with similar goals or constraints?
Share the business need, desired outcome, timeline, and expected investment. InnoNative will review the information and recommend a next step when there is a potential fit.