# Git automation and the queue connection

> Why Statamic content commits must run on the instance serving your site.

Git automation and the queue connection

Statamic writes content changes to disk as files. Those files are written by the instance that serves your site, so the commit has to happen there too. A commit made anywhere else looks at a copy of your application that never received the change, sees a clean working tree, and does nothing at all.

## The symptom

This failure is quiet, which is what makes it confusing:

- You save an entry or upload an asset in the control panel.
- The change appears under Utilities > Git.
- The queue job runs and completes without an error.
- No commit is created, and the change stays listed under Utilities > Git.

If that matches what you are seeing, the commit is running somewhere other than the instance serving your site.

## What Ploi Cloud does for you

Every Statamic application is given `STATAMIC_GIT_QUEUE_CONNECTION=sync`. That keeps content commits on the instance serving your site, where the files are.

You can override it by adding `STATAMIC_GIT_QUEUE_CONNECTION` to your environment variables. Your own value always wins over ours.

## What a valid override looks like

The connection you name must resolve to the `sync` or `deferred` driver in your `config/queue.php`. It is the **driver** that matters, not the name, so a connection of your own is perfectly fine as long as it uses one of those:

```php
'git-sync' => [
    'driver' => 'sync',
],
```

Anything that hands the job to a background worker breaks automatic commits, including `redis`, `database`, `sqs` and `beanstalkd`. Those connections are processed by a separate worker that has its own copy of your application and cannot see your content changes.

## On Laravel 13, prefer deferred

Laravel 13 added a `deferred` connection that runs the job in the same process, after the response has been sent to the browser:

```
STATAMIC_GIT_QUEUE_CONNECTION=deferred
```

The commit still happens on the same instance, but your save returns immediately instead of waiting for git. Check that `config/queue.php` actually defines a `deferred` connection before switching, because dispatching to a connection that does not exist throws an error on every save.

## Pushing

Ploi Cloud also pushes for you. A background process on your instance pushes any local commits to your repository within 30 seconds. That means you can set `STATAMIC_GIT_PUSH=false` to keep the network out of the save entirely, and a push that fails for a transient reason is retried on the next cycle.

What that background process cannot do is commit. If commits are not being created in the first place, there is nothing for it to push.

## If commits still are not happening

Check whether your build commands include `php artisan config:cache`. Config caching during the build freezes your configuration before the environment variable exists, so this setting is ignored entirely. Either drop it from your build commands or run it as an init command instead.

## Every combination

| Configuration | On content save | Result |
|---|---|---|
| Git integration disabled | nothing | the Git utility is unavailable |
| Statamic Pro disabled | nothing dispatched | changes list forever, it is a licence issue |
| Automatic committing off | nothing until you click Commit | working as configured |
| `sync` driver | commits and pushes during the request | correct |
| `deferred` driver | commits and pushes after the response | correct, and saves stay fast |
| `redis` or `database` driver | job completes, commits nothing | broken and silent |
| Worker-backed driver, no worker running | job queues forever | broken and silent |
| Connection not defined in `config/queue.php` | error at dispatch | every save fails |
| `STATAMIC_GIT_REMOTE` removed | commits normally, pushes to `origin` | pushing works, automatic pulling stops |
| `STATAMIC_GIT_PUSH=false` | commits locally | pushed by the background process within 30 seconds |
| `config:cache` in build commands | the cached config wins | this setting is ignored |

One consequence worth knowing: while content changes sit uncommitted, your site also stops picking up commits pushed from elsewhere, because the working tree is not clean enough to update safely. Getting commits working again restores both directions.