Hit publish. The site is live.
Going live normally means servers, certificates, a deploy pipeline, and a rollback plan. Creght folds all of it into one button: each publish creates a version, and you choose which version your domain points to.
Direct answer
What does publishing in Creght actually do?
When you publish, Creght records a version snapshot of the site source and deploys the site to the access node you selected, serving it over HTTPS. You do not provision servers, request certificates, or run a deploy script.
Each domain can either follow the latest publish or stay pinned to an earlier version — undoing a bad release means pointing the domain back one version, not redeploying.
The problem
The hard part of shipping was never the pages.
Finishing the pages is the start. The time goes into delivering them reliably — and into being able to go back when something breaks.
| Without Creght | With Creght |
|---|---|
| Buy a server, set up the environment, configure Nginx, then maintain all of it. | No server to run. Publishing is hosting. |
| Request a certificate, wire up HTTPS, watch the expiry date. | HTTPS is on by default. Certificates are not your problem. |
| A bad change means restoring a backup or redeploying old code. | Every publish is a version. Point the domain back one version. |
| DNS, redirects, and the 404 page each live somewhere else. | Custom domains, redirects, and a custom 404 are all in site settings. |
How it works
What publishing actually does
Publish is live, and reversible
The site is reachable right after you publish — no build queue or deploy script. Each publish records a snapshot of the source, and a domain can follow the latest publish or stay pinned to an earlier version, so undoing a bad release means pointing the domain back, not redeploying. Note that snapshots cover source only: a rollback does not restore CMS content, which is live.
Domain
Version history
- Version #259007-30 16:16 · publishCurrent
- Version #220707-27 22:13 · publishpublish
- Version #220107-27 22:10 · auto_before_editauto
Access nodes
HTTPS certificates handled by the platform
Custom domains with automatic HTTPS
CNAME your domain to the site entry, verify DNS, and it is connected. The platform issues and renews the certificate — nothing to request or watch for expiry. Custom domains, their SSL, and the ICP filing code are paid-plan entitlements; the free plan includes a publicly reachable subdomain.
Connect a custom domain
At your DNS provider, CNAME your domain to the site's system domain.
CNAME → yoursite.site.creght.cn
Back in the domain panel, hit verify. Once resolution propagates, the domain is connected.
Verify DNS
HTTPS turns on once connected; the platform issues and renews the certificate.
HTTPS enabled
Custom domains, their SSL, and the ICP filing code are paid-plan entitlements. The free plan includes a publicly reachable subdomain.
Mainland China and Hong Kong nodes
A site can run on the mainland China node or the Hong Kong node: the former is available on every plan, the latter requires a paid plan. Switching takes about 10 minutes to take effect.
Access node
Mainland China
Available on every plan
Hong Kong
Requires a paid plan
Switching nodes takes about 10 minutes to take effect.
Redirects and a custom 404
URLs you change can get permanent redirects that return 308, so old links do not die, and the 404 page can be replaced with your own design instead of a default error page.
Redirects and 404
- /old-price/price308
- /blog/2024/blog308
/404
Unknown paths land on your own 404 design, not a default error page.
Related docs
Step-by-step guides
Build the site first. Shipping is the easy part.
Describe what you need, let AI generate a complete site, edit until it is right, then publish. Free to start, no server required.