Deploy and update your code

What this page is for. Bring new 6ammart code onto the live server safely — by hand, by uploading a new zip, or automatically on every git push.

You need

• 6ammart already installed here (Install your 6ammart code).
• For the git paths: the server able to read that repository by itself — see Put your code in a git repository, section 5.
• Your new code pushed to the branch the panel deploys, or the new zip on your computer.
• A recent backup, if the change is a big one (Backups).

Do this first — this page is about your 6ammart code. Updating SixPanel itself is a different thing on a different page: Update SixPanel itself. Mixing the two up is the most common misunderstanding in this product.

Four ways to run an update

They all end in the same safe sequence, and they all appear in the same Deploy history.

The three git paths need the server to reach your repository on its own. The token you typed at install time is not kept. Create the read-only deploy key on the Deploys page — section 5 of Put your code in a git repository — and all three start working.

1. The Update button

The Deploys page opens with one screen that answers three questions: is my project live, which version is running, and what do I press. When the project is installed from git, the button on it is Get the latest code.

1. Open Deploys.
2. Press Get the latest code.
3. Read the preview. It tells you:

• how many updates you are behind, and on which branch,
• the list of changes, with who made each one,
• whether database changes are included,
• whether dependency changes are included.

1. Press Back up first if the change looks big. It takes you to the Backups page.
2. Press the button that starts the deploy.

If nothing is waiting, the preview says your site already runs the newest code and there is nothing to do.

Expected result: the live log ends with the update finished, and a new row appears at the top of Deploy history.

The site may pause for a few seconds while the caches rebuild.

This cannot be undone — database changes run during a deploy and a rollback does not reverse them. Take a backup before a release that includes them.

1b. Update from a zip

If you installed from a CodeCanyon zip, the same first screen offers Update from a zip instead.

1. Press it and choose the new zip.
2. Confirm. The upload starts, and the progress is on screen.
3. The panel unpacks it into a staging area first, finds the Laravel root, and only then lays it over your code — so a half-finished upload can never leave a half-finished site.

Your .env and your uploaded files are left alone. After the files land the panel runs the same tail as any other deploy: Composer if the lock file changed, database migrations, cache rebuild, then PHP reload and the workers restarted.

The panel keeps its own history of the zips installed here, so rollback still works on a zip project — it puts the previous zip's code back.

2. Automatic deploys on every push

One webhook per repository

You can run two repositories for a project: the admin app (the panel, the API, the apps' backend) and the customer website. Each one gets its own webhook, with its own address and its own secret. You can connect them separately, and replacing one secret does not touch the other.

Both addresses use your project's own domain, not the panel's. Your domain already reaches this server from the internet, so the panel port never has to be open for this, and GitHub is never told where your panel lives.

Always copy the address from the panel rather than typing it from this page.

Turn one on — the panel proves each step

Setting this up is a small wizard. It does not switch deploys on when you press the first button; it switches them on when it has evidence the connection works.

1. Open Deploys, find the repository's automatic-deploys card and press Set up automatic deploys.
2. Get the address — the panel shows the address and the secret, with the GitHub fields underneath.

Save the secret now. This is the one moment it is on screen. You can ask for it again later, but you have to confirm it is you first.

At this point the card reads almost ready. A push right now is checked and written down — and deploys nothing. That is deliberate.

1. Give this server read access. The card called Read access for this server creates a read-only deploy key and shows you the public half; paste it into your repository's Deploy keys with write access left off. A push that reaches a server which cannot read the repository would fail at the first step, so the wizard asks for this before it goes live.
2. Paste the webhook fields into GitHub (next section), then come back and press Check the connection. The panel sends itself a signed test delivery over the public address, looks at the certificate GitHub would see, and reads whether a real delivery from your repository has arrived and verified.
3. When the check passes, press the button that switches automatic deploys on. The card turns to working.

If you skip straight to the last step the panel refuses and tells you to run the connection check first.

The customer website card stays disabled until the website itself is installed. Install it first — see The customer website.

Fill in GitHub

Open your repository on GitHub → Settings → Webhooks → Add webhook, then enter:

Press Add webhook.

Do this once for each repository, with each repository's own address and secret. Pasting the admin secret into the website's webhook does not work.

application/json is the one to pick. The other option, application/x-www-form-urlencoded, also works — SixPanel checks the signature against the raw message either way, and reads both shapes. So if your git service only offers the other one, that is fine.

Fill in Gitea or Forgejo

Repository → Settings → Webhooks → Add webhook → Gitea. Same address, same secret, method POST, content type application/json, trigger on push. SixPanel accepts both GitHub's and Gitea's signatures.

See the secret again, or replace it

Two buttons sit under each block that is turned on:

• Show the secret again — the panel asks for your password (and your 6-digit code) first, then shows it. Anyone holding that secret can start a deploy on your site, so do not paste it into a chat or a support ticket.
• Replace the secret — a new secret is issued at once and the old one stops working immediately, so the webhook in GitHub fails until you paste the new one in. Use it if you think the old one was seen by someone else.

What happens on a push

The public web server passes the message to the panel. The panel checks the signature, then runs the exact same job the Get the latest code button runs. You watch it in Deploy history like any other deploy.

Some pushes are ignored on purpose, and the panel records why:

• a push to any branch other than the one shown as the deploy branch,
• a delivery that was already processed,
• a delivery whose commit is more than five minutes old (a late retry),
• a push that arrived at the wrong address — the website's repository pushing to the admin webhook, or the other way round,
• a push from a repository that is neither your app nor your website.

Deploys never overlap. A push that arrives while a deploy is running is handled after it.

If you set this up on an older build

Older servers had one shared address for both repositories, and the panel worked out which one had pushed by reading the message. That still works exactly as it did, and needs no action from you. The panel shows it folded away, marked as the old way.

To move to the new way: add the new per-repository address in GitHub first, check that a push deploys, and only then turn the old shared block off.

Turn one off

Press the off button on that repository's block. Pushes to it stop deploying and its secret is deleted, so the webhook in GitHub stops working. Turning it back on later gives you a new secret to paste in. The other repository is not affected.

3. Over SSH

sudo sixpanel deploy preview   # what would be pulled — changes nothing
sudo sixpanel deploy           # pull, migrate, rebuild caches, restart workers
sudo sixpanel deploy history   # recent deploys and how they ended

sudo sixpanel deploy means your 6ammart code. sudo sixpanel server update means SixPanel itself. They are different commands because they are different things.

sudo sixpanel deploy history --repo react shows the customer website's deploys instead of the admin app's.

History and going back

Deploy history on the Deploys page lists every install, update and rollback for that repository, newest first: when it ran, which version, what changed, whether it worked, and what triggered it (by hand, git push, or rollback). Each row opens its full log.

To go back, press Roll back to this on an older row and confirm. The rollback is itself a deploy, with the same safe sequence, recorded in the history.

This cannot be undone — a rollback moves your code back. It does not move the database back. If a bad release also changed the database, restore a backup from before it instead: Backups.

What actually runs

Every update — button, zip, push, or command — runs this sequence and stops at the first failure:

1. Refuse to continue if the code folder has been edited by hand on the server (git installs only).
2. Bring in the new code: pull fast-forward only, or lay the new zip over the checkout.
3. Clear the app's caches.
4. Apply database changes (migrate).
5. Install PHP libraries, but only if the lock file changed.
6. Rebuild the caches.
7. Reload PHP and restart the queue worker and the scheduler.

A rollback does the same, except that it moves the code to the chosen version instead of pulling the newest one, and it does not run database changes.

Everything that touches your code runs as the project's own Linux user, never as root. That is why a file the panel wrote is always readable by the app and never leaves you with a folder the site cannot write to.

How to check it worked

• Deploy history shows a new row with a green result.
• The top row carries the live badge and the version you expected.
• Your site loads and the change is visible.
• Server → Health is still green, including The app answers requests.

If it went wrong

The update refuses to start: local changes Somebody edited files on the server through the Files tab or over SSH. A deploy will not silently throw that away.

The deploy log names the files. Open the failed row's log and read the lines above the failure — up to the first fifteen changed files are printed there. You can also list them yourself over SSH:

sudo sixpanel exec php git status --short

That runs inside your project's code directory, as the project's own user. A line marked M is an edited file. A line marked ?? is a new file that is not in git. The app's own .env is ignored by this check, so it never appears as a problem.

The clean way out is to make the same change in git and push it. If the edit was a mistake and you want it gone:

This cannot be undone — the command below throws the hand edit away for good. There is no copy of it anywhere. If you are not sure what was changed, run the status --short command above first and read the list.

sudo sixpanel exec php git checkout -- .

That restores the edited files. Files marked ?? are new and stay — delete those through the Files tab, or add them to git.

"could not check the repository for new commits" The server cannot read your repository by itself. Create the read-only deploy key on the Deploys page and paste it into the repository — section 5 of Put your code in a git repository.

GitHub shows a red delivery with 401 There are three causes, and the content type is not one of them. Either that repository's webhook is turned off in the panel, or GitHub sent no signature at all (the Secret box on the webhook is empty), or the secret does not match — often because the admin secret was pasted into the website's webhook. Press Replace the secret on the right block, paste the fresh secret into GitHub, then use GitHub's Redeliver on a recent delivery to test.

GitHub shows green but nothing deployed Three things to check, in order. The address: a push that lands on the other repository's webhook is accepted and then ignored, and the panel says so in the activity log. The branch: only the deploy branch deploys. Then Deploy history: a delivery can be accepted and the job still fail, and the reason is in the job log, not in GitHub.

The deploy failed part-way The log names the failing step and the update stops there. Nothing after that step ran. Fix the cause and deploy again.

The site broke after a good-looking deploy Press Roll back to this on the previous row. If the release also changed the database, restore a backup instead.

More causes and fixes: When something is broken.