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).
• The 6amMart addon active on this server, or a shop covered from before addons — its Deploys page says "Installed before addons, so it keeps updating". Rollback and the deploy history never need it.
• 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.

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

If nothing is waiting, the preview says your site already runs the newest code on its branch and offers Deploy again. For the admin app that re-runs every step on the code already on the server — dependencies, database changes, caches and a reload. Use it when the app misbehaves after a change made outside the panel, or after a deploy that failed part-way once you have fixed the cause. For the customer website it rebuilds the site from the code already there and restarts it.

Force deploy (discard local changes) appears beside it only when files on the server differ from the repository — the dialog says how many — or when the panel could not check. It asks first, and it throws those edits away for good. For the admin app a normal deploy stops rather than discard them; the customer website's deploy keeps them, and stops only if an update changes one of those same files.

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. So are the translations you typed on the admin panel's Language screens, and any language you added there — the zip does not replace them. 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 (and a running websocket server) 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.

3. 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.
4. 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.
5. 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 you to confirm it is you first (your 6-digit code, or your panel password when two-factor login is off), 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 — unless it is the branch a staging site of this project follows: that push deploys the copy (one webhook serves a project and its copies),
• a push the panel made itself — a staging site's Commit and push, production's commits brought into a copy, a Promote — because the job that pushed it is the one deploying it,
• 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.

A push that moves the deploy branch back to an earlier commit is not deployed either, and it is not silent: the deploy stops at its first step and says which commit the branch now points at and which one your site runs. A deploy only moves forward. To put the site on the earlier commit, use Rollback in Deploy history. Pressing the button yourself in that state deploys the code already on the server again and says nothing was pulled.

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

deploy preview asks the running panel to check your repository, using the access token or deploy key the project already has stored — so it works for a private repository too. If the panel is stopped, nothing is fetched: the command says so and shows what the last check brought.

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 website shows the customer website's deploys instead of the admin app's. The flag takes admin or website and nothing else; any other word is refused with a usage error.

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.

Only the code moves. Your server's own settings (.env), your activation and module switches, and the translations you entered on the admin panel's Language screens stay exactly as they are.

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.

Test first, then promote

The Update button puts new code straight on the live shop. To try it first, make a staging site that works on its own branch: push there, test on the copy's own address with a copy of your real data, and press Promote — one job that backs up production's database, merges the branch into the deploy branch, runs this same update on production and checks it answers. If any of that fails, production is put back: the database from that backup, the code with this page's rollback. Staging & Testing → Working on a branch and promoting has every step.

Why the Files tab will not let you edit some files

If your project came from a git repository, the Files tab refuses to save, rename, delete or re-permission the files that git looks after — your PHP code, composer.json, artisan, the templates. The refusal names the way out and includes the exact command for your project.

That is not the panel being awkward. A deploy refuses to run while the code folder carries a change made on the server, because it will not silently throw your work away — see the local-changes section below. So one Save on a tracked file used to stop every later deploy of that project, the push webhook included, and the only way back was a git command the panel does not offer. Refusing the edit up front is the smaller inconvenience.

The way to change that code is the way the rest of this page describes: make the change in your repository, push it, and deploy.

sudo sixpanel --project <slug> deploy --yes

What stays editable, because these are files the panel or the running shop writes itself and a deploy already expects to find changed:

• the app's own .env settings file — the App .env page and the Files tab both keep working on it;
• your customer uploads — product images, logos, documents;
• the couple of settings files 6ammart writes itself as you use the admin panel, such as its record of which modules are switched on.

If your project was installed from a zip, none of this applies: there is no git repository to keep clean, so the file manager stays exactly as it was and every file is editable. That is deliberate — most 6ammart installs are zip installs from CodeCanyon, and locking their owners out of their own editor to enforce a rule about a repository that is not there would be the worse outcome.

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, unless they were already installed from the same lock file. An update you run again after it failed part-way installs them too.
6. Rebuild the caches.
7. Reload PHP and restart the queue worker and the scheduler — and the live updates (websocket) server too, if it is running, because it keeps the previous code in memory until it is restarted. A websocket server you switched off stays off.

If the update stops at step 1 or 2 — it refused over a hand edit, the repository could not be reached, or the branch was rewritten — the files that are yours are left exactly as they were: your .env, the translations typed into the admin panel, your activation and your module switches.

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 update dialog's Force deploy (discard local changes) button is the in-panel way past it — it discards the listed edits for good, so read them first.

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 --project <slug> exec php git status --short

Replace <slug> with the project's short name — sixpanel project list prints them. On a server with only one project you can leave --project out.

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 --project <slug> 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.