The customer website

What this page is for: put the separate React storefront — the website your shoppers browse — on its own domain, next to the 6ammart admin site.

You need

• Your website code, in one of two shapes:
• the zip you downloaded from CodeCanyon (the "React user website" item), or
• the git repository URL of your customer-website code — this is a second repository, not the admin one. If it is private, you can use either an access token or this server's own deploy key; the screen asks which and walks you through it, exactly as the admin app's install does.
• A domain or subdomain for it, for example shop.example.com.
• Your 6ammart admin app already installed and working.

The customer website is not an add-on nobody uses: it is how customers order from a browser rather than from the phone apps. A project can sell through the apps alone, and some do, but most people want both.

1. Deploy the website code

1. Open the project's Deploys page (in the Project menu group).
2. Find the Customer website section.
3. Choose where the code comes from:

• From a zip file — pick your CodeCanyon website zip. Upload the whole download if you like: it usually contains the site and a "changed files" folder for people upgrading by hand, and the panel takes the complete one and says in the log which it skipped.
• From a git repository — paste the repository URL. The screen then asks how this server should read it:
• HTTPS — with an access token. Leave the token blank for a public repository; paste one only if it is private.
• SSH — with this server's deploy key. Nothing secret is stored here: the panel makes a key, you add it to the repository, and the server uses it from then on. This is the website's own key, separate from the admin app's, so the two repositories can use different keys.

Then press Test connection. It answers in about a second — whether the server can read the repository, and which branches it has — so you pick the branch from the real list instead of typing one, and a wrong token is found now rather than several minutes into a build. The install button stays off until that test passes.

4. Press the install button.

The job unpacks or downloads the code, installs its dependencies, builds the site, points it at this project's admin address and starts its service. On a small server the build takes several minutes and uses a lot of memory — this is the heaviest thing that ever runs on the machine, which is why the installer adds swap space on servers with little RAM. Watch the log; the last lines say the website is running.

The build happens here, on your server. There is nothing to build on your own computer and no need for Node.js anywhere else — SixPanel installs the Node version the storefront needs as part of the server setup.

Later, a newer zip is uploaded the same way: the Customer website card offers Upload a newer website zip once a site was installed from one. Your settings survive; only the code is replaced.

Before the website exists

The moment you give the storefront a domain, that address gets a certificate and starts working — and until you have deployed the site, it serves a short page saying the shop is not open yet and pointing back at this step. That is normal. It disappears by itself the moment the storefront starts.

2. Give it a domain

1. Open Domain & SSL (in the Project menu group).
2. Find the Customer website section and press Add domain.
3. If Cloudflare is connected, the panel creates the DNS record for you, proxied. Otherwise add an A record for that name at your DNS provider, pointing at this server's IP address — the page prints it for you.
4. Press Re-check DNS until the name shows pointed.
5. Press Get free SSL.

When you created the project from a single domain, this name was already suggested and registered for you — usually the domain itself, plus www.

3. Turn the website service on

1. Open Advanced → the Services tab (in the Project menu group).
2. In the Customer website card, turn it on.

The first deploy already starts the service, so this card is mostly for turning it off and on again later. The card also tells you when the website is one of the things your project still needs.

Over SSH, the same two actions:

sudo sixpanel service enable react
sudo sixpanel service disable react

disable only stops it now. It is not remembered: sixpanel service start all and the panel's own Services tab both bring it back. To turn it off for good, use the switch on that tab — the panel records that as your decision and never starts it again by itself.

How the website is started. When the start script in your website's package.json is the usual next start (with or without a port of its own), the panel starts Next.js directly: one process, and roughly 80 MB less memory per website than starting it through npm. Anything else is run through npm run start exactly as you wrote it — a custom server, a wrapper, settings in front of the command, a prestart or poststart script, a config block in package.json, a Node.js of its own installed with the website (the node package), or an .npmrc file in the website folder. The panel reads the script again at every deploy. If you change it by hand to something other than next start, restart the website from the Services tab once: from then on the panel runs your script through npm. A restart typed over SSH does not re-read it.

If a website ever fails to come up when started directly but runs under npm, the panel switches it back to npm run start by itself and keeps it there.

4. Update it later

Open Deploys → the Customer website section and press the update button. It pulls the newest code, rebuilds and restarts the site.

Your shop stays up while it builds. The new version is built in a separate folder beside the live one, and only a build that finished is switched in — the switch and the restart take a few seconds. If the build fails (a code error, or the server ran out of memory), nothing on the live website changes: it keeps serving the version it had, and the job log says why the build stopped.

If you set up push-to-deploy, a push to the website repository does this by itself. The website has its own webhook address and its own secret, separate from the admin app's — set it up once on the Deploys page. See Deploy and update your code.

5. Pages are kept for ten seconds

The customer website builds every page afresh each time somebody asks for it, and it can build only about a dozen a second. So the web server in front of it keeps a page for ten seconds and gives the same copy to the next visitor — but only to a visitor who is nobody in particular: not signed in, and whose browser sends nothing back with the request (no chosen language, no theme, no cart). The moment a browser sends such a choice, or a sign-in, that visitor's pages are built for them alone, every time, and are never kept.

So it helps where it matters most: somebody arriving for the first time, a search engine reading your pages, and a sudden crowd of either — thousands of requests a minute for one page reach the website as a few dozen. A shopper who has already used the website still has every page built for them alone — by a website that is no longer busy building the same page for every passer-by.

What that means for you:

• A change you make in the 6ammart admin — a banner, a price, a new item — can take up to ten seconds to appear for people who are only browsing. When a page's ten seconds are over, the next visitor's request builds it again, and anybody who asks during that one build is given the previous copy instead of being made to wait — so on a busy website a page is at most ten seconds old, plus the moment it takes to build.
• A page you remove, or one that stops being public (it now asks for a sign-in, or sends visitors elsewhere), has no new copy to take the old one's place. A visitor who asks for it alone gets the true answer at once. But while several ask at the same moment, all of them except one are still shown the old page, for up to a minute and forty seconds — never longer: every kept page is dropped for good at the end of its hundred seconds, whatever happened to it.
• Each kept page is dropped once every hundred seconds and built again the first time somebody asks for it — each at its own moment, not all together, so on a busy website whose visitors are spread over many different pages those first builds come one after another and nobody queues behind them. Right after an Update or a Restart it is different: they empty the kept pages at once, the first builds do come together, and because the website builds one page at a time a page can take seconds instead of a fraction of one for a few seconds — for signed-in shoppers too.
• A page the website itself marks as private (checkout, profile) is never kept, whoever asks for it. Neither is anything that is not an ordinary page: images and other files, and the website's own /api/ addresses, are passed straight through as before.
• Update and Restart from the panel empty the kept pages at once, so nobody is shown a page from the version you just replaced. A restart over SSH (sudo sixpanel service restart react) does not; each kept page is built again by itself the first time somebody asks for it after its ten seconds.
• If the website stops answering while it is still running (it hangs), people who are only browsing can go on being shown the kept pages until those are dropped — up to a minute and forty seconds — while a shopper who is signed in sees the fault at once. The Customer website line of the Health page asks the website itself, never a kept page, so it shows the fault straight away. A monitoring service of your own that asks the way an anonymous visitor does can be that minute and forty seconds late.
• A staging site never keeps pages — what you test is what runs.

See it yourself. Every page of the website answers with an X-Cache line:

From any computer, twice within ten seconds:

curl -sI https://shop.example.com/ | grep -i x-cache

The second answer says HIT. (About once in a hundred tries it says MISS again: a kept page starts afresh once every hundred seconds, and your two requests fell on either side of that page's moment. Ask a third time. The X-Cache-Slot line beside it is a number that changes at exactly that moment.) Your own browser usually shows BYPASS once you have used the website: it remembers your language and theme and sends them with every request.

A page that is never kept says MISS every time, and that is correct: checkout, profile and the other pages the website marks as private, and an address that does not exist.

How to check it worked

• Open your website domain in a browser. You should see the storefront with a padlock in the address bar.
• Domain & SSL shows the website name as secured.
• Advanced → Services shows the customer website running.
• sudo sixpanel service status react prints it as running.

If it went wrong

• The build failed — read the job log on the Deploys page. A wrong branch name, a private repository the server cannot read, or a server that ran out of memory during the build are the usual causes. For the second one, see the read-access key in section 5 of Put your code in a git repository. Your live website is unaffected either way. For the third, the build is given as much memory as is free when it starts (the build heap line in the log), so running the update again while the server is quieter often succeeds; if it fails again at the same size, the server needs more memory or swap.
• The domain shows the admin site, not the storefront — the domain was added under the wrong section. It must sit under Customer website on Domain & SSL.
• The page is blank or shows an error — read its log on the project's Logs page, or over SSH:

  sudo sixpanel logs react -n 100

• A change in the admin does not show on the website — wait ten seconds and reload. Pages are kept that long for visitors who are only browsing (see section 5 above). If it still shows the old content after that, it is not the kept pages: check that the change is saved in the admin.
• The folder is not empty — the panel refuses to clone into a folder that already holds files but is not a git checkout. Ask support before clearing it.

More symptoms: see When something is broken.