Sanity, n8n, and Hack Michigan: letting organizers ship during the event

By Gregor Projects

Hack Michigan is the latest public home for Michigan’s statewide hackathon—teams, schedule, prizes, and the story the community tells as the weekend unfolds. The site itself was a fast Astro build on Vercel; what it did not solve yet was who gets to add participant teams, projects, and scores, while developers are conducting user research for our next project. The development for this site was proposed to another developer. But it was highly designed to a point it would be difficult to make it perform well for accessibility and mobile devices. They were unsure they wanted to use their work. Becuase the event runner wanted the site to be live the following weekend, I created this site over a weekend as a backup in case the first project fell through. I promoted it internally to the Compass Detroit team and it was selected as the site for the May hackathon.

We were able to attract the original developer to join the team and they provided valuable fine tuning and feedback on the component development and CD/CI pipeline. That opened the door for me to take on adding the Sanity CMS and n8n deployment automation layer.

I spearheaded adding Sanity as the headless CMS, adding it in an evening after work. I proposed adding a method so that event volunteers could add updates and trigger a deployment. I leveraged n8n as the deployment automation layer. I built a ‘no-index’ page with a passcode and button so non-developers are able to contribute content during the event then publish the changes without repo access, CLI comfort, or Vercel dashboards.

Screenshot of the hackmichigan.com site showing our contributor deployment button.

This page is not indexed by search engines and is only accessible via the link from the event website. Keeping it as part of the original site was a requirement for how this works with the zero trust tunnel I setup for the deployment.

The problem in one sentence

Event sites die a little every hour they wait on a deploy key holder. We needed editorial speed with engineering guardrails.

Why Sanity

Sanity gives organizers a structured editing surface: fields, references, and validation instead of “find the right paragraph in a markdown file.” That maps well to hackathon content—sponsor tiers, FAQ blocks, schedule rows, prize callouts—where consistency beats free-form pages. They offer a generous free plan allowing for other team members to add and edit content.

From the engineering side, the front end keeps fetching typed content at build or runtime (depending on how you wire it), while the Sanity studio lives in the cloud, allowing for other team members to contribute. The event runners are exicited to have this flexibility and we may find this becomming a new standard for some event content management, above and beyond updating JS files as we have done in the past.

The role of n8n as a deployment automation layer

This is a workflow automation tool that allows you to create workflows that can trigger or be triggered by events. Ours is a self-hosted tool that can be installed on a private server. It is a powerful tool that can be used to automate a variety of tasks. This is only scratching the surface of what it can do. It is a popular tool for automation and is used by many organizations. It is a great fit for this project because it allows us to create a workflow that can trigger a deployment to Vercel when a change is made to the Sanity CMS. We’ve added a Cloudflare zero trust tunnel to the mix to secure the connection between the two services.

Why n8n sits next to it

Not everyone who should trigger a publish should have Vercel or GitHub permissions. n8n closes that loop: approved changes in Sanity can flow through a workflow that builds and deploys (or kicks your hosting pipeline) in a repeatable, auditable way. You keep governance with the core team while distributing the act of going live to people whose job that weekend is communications, not git. This was one of the first times I successfully integrated a headless CMS and a deployment automation layer into a project. Working with Cloudflare Zero Trust made all this so much more difficult but was a great experience and adds another layer of security to the project. I will be using it again in the future.

The combination is deliberately boring in a good way: editors work in Sanity; automation does the same deploy steps a maintainer would have run by hand—just on demand and with fewer footguns.

What this unlocks in May

  • Faster corrections when a room changes, a sponsor logo lands late, or copy needs a tone fix between sessions.
  • Less developer load during the hours when engineering attention should be on participants and systems, not content tickets.
  • A template for other Compass event properties that have the same “small team, big weekend” pressure.

Context on the site

Hack Michigan sits alongside other Compass Detroit work I’ve written about in the portfolio under Pro-bono web work with Compass — summits and Hack Michigan. That piece covers the broader arc; this post is the operational slice: CMS + automation so the right people can ship when it counts.

If you are weighing a similar setup—headless CMS plus workflow-driven deploys for a static or hybrid front end—the honest tradeoff is upfront integration time against every hour saved when your team is mid-event. For a statewide hackathon in May, that tradeoff was easy to justify.