How does Git Sync handle merge conflicts on playbooks?

OpenClaw validates the incoming commit against the current workspace state, then blocks the sync if a playbook file has diverged. You resolve the conflict in your Git provider and push a new commit. Once the branch merges cleanly, OpenClaw applies the change set atomically so either all updates land or none do.

What secrets are available inside preview environments created from branches?

Preview environments use a scoped secret set that inherits from workspace defaults but excludes production-only credentials. You can add branch-specific API keys and test tokens so calls hit sandboxes by default. Secret reads are audited, and previews never expose production webhooks or keys.

Which branches create a preview and how do I control scope?

By default, pull request branches matching your configured pattern spin up a preview. You can target specific prefixes, for example pr/* or feature/*. You also define TTL and inactivity timeouts so previews auto-pause and later clean up without manual work.

Can I require CI checks before a sync reaches production?

Yes. Git Sync honors your repository status checks. You can require unit tests, lint, or security scans to pass and also require review from code owners. OpenClaw only applies updates from the main branch after those checks are green and the merge completes.

How do rollbacks work if a preview is merged and production breaks?

Every sync produces an immutable deployment record with a diff. You can roll back to any prior good state with a single action, which reapplies the previous playbook versions and variables. For fast mitigation, you can also pause schedules while you triage.

Are preview environments billed and how can I control costs?

Previews count toward your active environment quota while they are running. You can cap concurrent previews per workspace, set auto-pause after inactivity, and define TTL. These controls keep experimentation fast while avoiding surprises on your invoice.

Git Sync and Preview Environments Arrive for Workflow Automation in OpenClaw

TL;DR

OpenClaw now lets you connect a Git repository to your workspace and spin up branch based preview environments before you merge. That means you can test message templates, event mappers, and agent behaviors in isolation, then promote with a clean history. Teams that rely on workflow automation get safer rollouts without slowing down shipping. The update ships with branch rules, scoped secrets, and one click rollbacks so experimentation stays fast while production stays stable. You keep production steady while reviewers exercise each change in a safe sandbox.

What We Shipped

This release brings source controlled playbooks and ephemeral previews to the same place you already run your AI agents.

Git Sync connects one or more repositories to a workspace and maps folders to playbooks, variables, and connection configs.
Preview Environments create a fully isolated sandbox for each pull request or branch that matches your rules. Previews run the same jobs with their own schedules, queues, and webhooks.
Branch Protection respects your repository checks so only code that passes CI and review reaches the main line.
Scoped Secrets and Config ensure previews use test credentials and never touch production data unless you opt in.
Rollback and Audit give you a deployment timeline with diffs and a single click revert to prior known good states.

If you are new to the product, a quick pass through the AI marketing automation features shows how Git Sync and previews fit alongside playbooks, channels, and analytics. See the feature set for context.

Why This Matters

Marketing teams increasingly ship with the same rigor as software engineering. Git centered workflows, CI checks, and environment gates cut errors and improve confidence. Independent research on software delivery performance shows that teams with strong CI and fast feedback deploy more often with lower change failure rates. See the summary of the DORA research on deployment frequency and change failure rate for background.

On the execution side, previews are a proven pattern in modern hosting platforms. They let reviewers try a change as it will run in production, but without risk. If you have used Vercel or similar platforms, the idea will feel familiar. Their documentation on Vercel Preview Deployments outlines the core mechanics this release brings to OpenClaw workflows.

Finally, connecting automation to source control makes ownership and change control clearer. You get reviews, code owners, and a durable history. For environment gates and protection rules, the GitHub environments documentation explains the model we integrate with.

How Git Sync Works

At a high level, you map a repository, choose a sync mode, then define branch rules and preview patterns. The workspace watches for commits and applies validated changes.

Step 1Connect a repository

From your workspace settings, link a GitHub or GitLab repository. Select the default branch that represents production. You can connect a monorepo and point to a subfolder that contains your OpenClaw artifacts.

Step 2Map playbooks and config

OpenClaw reads a small manifest that declares where playbooks, variables, and connection files live. You place it at the repository root or under a selected folder.

# openclaw.yaml
version: 1
playbooks:
  - id: pb_welcome
    path: playbooks/email/welcome.yaml
  - id: pb_abandon_cart
    path: playbooks/shopify/abandon-cart.yaml
variables:
  path: config/variables.yaml
connections:
  path: config/connections.yaml
sync:
  mode: gated  # options: immediate, gated
  branch: main
  preview:
    pattern: "pr/*"
    ttlHours: 72

In immediate mode, commits to the default branch apply as soon as checks pass. In gated mode, changes queue until a release manager promotes a batch.

Step 3Choose sync strategy

You decide how aggressive the workspace should be when applying changes.

Immediate. Great for high velocity teams that trust CI and code owners.
Gated. Use this when you want scheduled releases or human review after CI.
Batched. Accumulate multiple small tweaks and promote them together to reduce operational noise.

Step 4Set branch rules

Define which branches create previews. Many teams use pr/* or feature/* patterns. You also select which checks must pass. Typical examples include unit tests for template helpers, schema validation for event mappers, and lint rules for playbook YAML. If a check fails, OpenClaw does not apply the change.

Step 5Review and merge

When reviewers approve, merging into the default branch triggers a production deploy. The deploy is atomic. Either all targeted playbooks and config apply or nothing applies. The deployment record includes the diff, the author, and the related pull request.

How Preview Environments Work

Previews clone the runtime that production uses, but with different inputs and outputs. They receive their own webhook URLs, scheduled jobs, queues, and logs. Each preview is tied to a branch and is ephemeral by default.

Step 1Create a branch

Create or update a branch that matches your preview pattern. OpenClaw sees the commit and spins up an environment with an isolated datastore, queues, and a set of branch specific secrets.

Step 2Route safe traffic

Use test event sources and sandbox credentials. For example, send Shopify or Stripe events from a staging store or test account. Preview webhooks are unique per branch. They are easy to share for review, but cannot be promoted directly to production without merging the branch.

Step 3Validate behavior

Run end to end flows. Confirm that journeys enqueue correctly, agent prompts resolve as intended, and third party APIs respond as expected. If you need to pause or resume schedules for the preview, you can do so without touching production.

Step 4Decide to merge, iterate, or close

If the change is ready, merge the branch. If not, push new commits and the preview updates in seconds. When the work is done, close the pull request and the preview auto cleans up after its TTL or inactivity window expires.

Migration Guide: From Ad Hoc Edits To Source Controlled Automation

Many teams start by editing playbooks directly in the UI, then graduate to source control once collaboration and release coordination become important. Here is a safe path to adopt Git Sync without interrupting delivery.

Step 1Export current state

Use workspace export to capture the current playbooks and variables, then commit them as your initial snapshot. Keep the default branch protected while you test the path.

Step 2Stand up a pilot repo

Create a repository that mirrors your existing playbook layout. Add the openclaw.yaml manifest and point the workspace at this repo in gated mode. Start with a low risk playbook such as a lifecycle email or a simple webhook transformer.

Step 3Use diffs to build confidence

Every proposed change shows a textual diff before it applies. If you want a deeper safety net, pair Git Sync with diff and dry run mode for safer changes. That combination makes it clear exactly what will change and how many records or messages will be affected.

Step 4Expand coverage

Once the pilot feels natural, move more playbooks and connection configs under Git. Define code owners for sensitive folders and require review. As the main branch becomes the single source of truth, the UI reflects the repository state.

Step 5Turn on previews for pull requests

Enable preview environments for your preferred branch pattern. Share preview URLs with stakeholders so they can test flows and content before merge. Previews will auto pause after inactivity and clean up after the TTL you set.

Security, Compliance, and Governance

Your workspace already supports granular roles. Git Sync builds on that. Only members with the appropriate permissions can connect repositories, change branch rules, or promote deployments. Actions are recorded to the audit log with the actor, timestamp, and payload.

Secrets are scoped to their environment. Previews inherit non sensitive defaults, but you can define overrides for API keys and data stores. A common pattern is to make production keys unavailable to previews so test traffic cannot leak into live systems.

If you are new to ButterGrow and want a product level view, check ButterGrow's platform and the overview of AI marketing automation features. For step by step enablement, the onboarding flow under answers to common questions covers account setup and permissions.

Performance and Cost Controls

Previews cost nothing when paused. You define inactivity windows, hard TTLs, and concurrency caps so that your workspace runs only what you need. When a preview is paused, schedules stop, queues drain, and workers scale to zero.

Because previews share the same engine as production, performance characteristics match closely. This removes the guesswork that often plagues staging systems that drift over time.

Practical Use Cases

New event mapper. Add a transformation for a Shopify or Segment event, validate the schema, and watch the preview logs to confirm downstream calls.
Message variant testing. Try new copy or images for an onboarding email sequence. Keep design reviews inside the preview without risking live traffic.
Third party integration changes. Swap API versions, rate limit policies, or retry logic and see how the agent pipeline behaves with real sandbox responses.
Team onboarding. New contributors can open a simple pull request and get a full environment without asking for manual staging access.

Rollback, Incident Response, and Audit

Every deploy produces a record with the diff, the committer identity, and links back to the pull request. If something looks off, you can roll back to any prior deployment. For incidents, you can pause schedules, drain queues, and cut over traffic while you investigate. The audit trail captures who did what and when so postmortems are fast and factual.

Roadmap

We are continuing to invest in source controlled automation. On the shortlist are protected tags for emergency fixes, environment specific variables at the folder level, and richer code owner rules. Your feedback will shape the next round of improvements.

If you want to explore related capabilities, we recommend reading about our diff previews and validation features in the post linked above. For more background content, you can always find more from the ButterGrow blog.

Bringing Git and previews to OpenClaw makes your automation workflows easier to review and safer to ship. By fitting into the processes your engineering partners already trust, you can move faster with fewer surprises.

To try Git Sync and Preview Environments in your own workspace, head to the onboarding flow and get started in minutes. You will connect a repository, choose a sync mode, and enable previews on your first pull request within a few minutes.

References

DORA research on deployment frequency and change failure rate: industry findings that link CI and deployment practices to reliability and speed.
Vercel Preview Deployments: reference pattern for branch based previews used by modern hosting platforms.
GitHub environments documentation: overview of environment protection rules and required checks.