How deployment triggers fit into a Git-backed publishing workflow

In a Git-backed publishing workflow, the moment your content lands in the repository feels like the finish line. It usually isn't. A commit changes a file; it does not, by itself, change what visitors see on your live website. That gap is exactly where deployment triggers do their work. A deployment trigger is the signal that tells your hosting provider to take the newly committed Markdown or MDX and rebuild the site so the change is actually live. Understanding where this step sits, and how to make it reliable, is one of the most practical skills for anyone running a static or Git-backed site.

This article walks through what happens after a commit, how a deployment trigger profile rebuilds the host, the difference between manual and automatic triggers, and how deployment visibility through logs lets you confirm that "committed" really became "live." If you have ever published a post and then refreshed your homepage to find nothing changed, this is the missing mental model.

A commit is not the same as live

On a Git-backed site, your pages are generated from source files. With a framework like Next.js or another static generator, the build step reads your content files, renders HTML, and produces the bundle your host serves. The published HTML a visitor sees was created during a build — it is not the raw Markdown sitting in your repository.

So when GitHub publishing commits a new Post or Page to your connected branch, you have updated the *source of truth*, not the rendered output. Two distinct things have to happen, in order:

1. The content file is committed to the repository on the configured branch and content path (for example, content/posts/).
2. The hosting provider runs a build using that new commit and deploys the result.

Step one is publishing. Step two is deployment. They are related but separate, and conflating them is the single most common reason people think "the publish didn't work" when in fact the commit succeeded and only the rebuild was missing.

What a deployment trigger profile does

In Acrosite, the rebuild step is handled by a configured deployment trigger profile attached to your Project. The profile holds the connection details your host needs in order to start a build — without ever exposing those details back into the dashboard UI. After a successful commit, the profile is what fires the signal to your hosting provider to begin a new build and deployment.

Most modern hosts expose some form of build hook or deploy endpoint for exactly this purpose. The deployment trigger profile is Acrosite's safe wrapper around that mechanism: it knows how to call the host, but the hook URL and any secrets stay hidden. You configure the profile once per Project, and from then on every publish can lean on it.

Where it sits in the publishing sequence

The end-to-end flow for a single Content Item looks like this:

1. A Team Member writes a Post, Page, or entry of a Custom Content Type in the dashboard.
2. The draft stays private in the app and can move through review.
3. On publish, Acrosite validates the content.
4. The Markdown or MDX file, with its YAML frontmatter, is committed to the configured branch and content path.
5. The commit SHA is recorded.
6. The configured deployment trigger profile signals the host to rebuild.
7. The host builds and deploys; the change becomes live.

The deployment trigger is step six. It is deliberately the last action, because there is no point asking the host to rebuild until the commit it should build from actually exists.

Manual versus automatic triggers

A deployment trigger profile can be set to fire automatically or to wait for a person. Both are legitimate; they suit different editorial rhythms.

Automatic triggers

With an automatic trigger, the rebuild fires immediately after a successful commit. This is the right default for most teams who want publishing to feel like a single action: approve, publish, and a few minutes later the page is live with no further clicks. It pairs naturally with scheduled publishing, where Acrosite holds the approved draft and, at the chosen time, commits the file and then triggers the rebuild — all without anyone being present.

Automatic triggers are ideal when:

• Each published change should go live on its own, as soon as it is ready.
• Builds are quick and inexpensive on your host.
• You publish steadily throughout the week rather than in big batches.

Manual triggers

A manual trigger commits the content but waits for a person to start the deployment. This is useful when you want to batch several changes into one build, when builds are slow or metered, or when a release should go live only at a coordinated moment alongside other work. The content is safely in the repository; you simply decide when the host rebuilds.

Manual triggers are ideal when:

• You are staging several Content Items and want them to ship together.
• Build minutes are limited and you would rather not rebuild per-commit.
• A launch needs to be timed with announcements, ads, or other teams.

A reasonable pattern is to use automatic triggers for routine blog Posts and a manual trigger for a coordinated campaign where timing matters across more than just the website.

Deployment visibility and logs

Because committing and deploying are separate steps, you need a way to see both — otherwise a failed build looks identical to a successful one until a visitor complains. Acrosite provides this through two distinct records.

Publish Logs record each publish attempt's steps: that the content was validated, committed to GitHub, the commit SHA saved, and the deployment triggered. They do this without exposing tokens, hook URLs, or raw provider payloads, so the log is safe to read and safe to share internally. If a publish fails partway, the Publish Log shows where it stopped, and the attempt can be retried where it is safe to do so.

Deployment Logs record the results of the deployment trigger itself — whether the host accepted the rebuild request and how it responded. Together, the two logs give you deployment visibility: a clear, separated answer to "did the commit happen?" and "did the rebuild happen?"

This separation is also what keeps the system honest. A commit can succeed while a build fails for reasons that have nothing to do with your content — a host outage, a build configuration error, an exhausted build quota. Surfacing the deployment result as its own record means you are never guessing.

A practical example: the configured path

The deployment trigger only matters in relation to what was committed, so it helps to see the commit it reacts to. A Post published to content/posts/ might land as a file with standard YAML frontmatter:

---
title: "Spring product update"
slug: "spring-product-update"
date: "2026-06-01"
status: "published"
description: "What changed this season and why."
---

The body of the post, written as Markdown, follows the frontmatter.

Once that file is committed on the configured branch, the deployment trigger profile signals the host. Your framework's build reads content/posts/, renders the new Post, and deploys it. The frontmatter fields map to whatever your templates and Custom Content Types expect — title, slug, date, SEO fields, and so on — so the rebuilt site picks up the new entry automatically.

What to test first

When you set up or change a deployment trigger profile, verify the full chain before you rely on it for real content. A short checklist:

1. Publish a harmless test Post (or a draft you can safely remove) and confirm the commit and SHA appear in Publish Logs.
2. Check Deployment Logs to confirm the host accepted the rebuild request.
3. Wait for the build to finish, then load the live URL and confirm the new content is actually there.
4. Test a manual trigger and an automatic trigger separately if you intend to use both, so you know each behaves as expected.
5. Try a scheduled publish at a near-future time and confirm the commit and rebuild fire on schedule, not early.
6. Deliberately leave a small detail to fix, publish again, and confirm the second build replaces the first cleanly.

Testing the chain end to end — commit, trigger, live page — is far more reliable than assuming a green checkmark on the commit means the site updated. Once you have confirmed the path works, day-to-day publishing becomes the simple, predictable action it should be.

Where it fits in the bigger picture

Deployment triggers are a small but load-bearing part of a Git-backed workflow. They are the bridge between your content staying versioned in your own repository and your audience seeing the result. Combined with review, scheduled publishing, and clear logs, they let non-technical contributors publish confidently while the underlying mechanics — commit, trigger, build, deploy — stay observable and safe. If you want to see how the pieces connect, the features overview and the documentation walk through each step in more depth.