docs/content/deploy/vercel.md (1785B)
1 +++
2 title = "Vercel"
3 description = "vercel.json, and why none of the framework machinery applies"
4 weight = 30
5 toc = true
6 +++
7
8 ```json
9 {
10 "buildCommand": "curl -sSL https://github.com/debuman/sqzass/releases/latest/download/sqzass-x86_64-unknown-linux-musl.tar.gz | tar xz --strip-components=1 && ./sqzass build",
11 "outputDirectory": "public",
12 "framework": null
13 }
14 ```
15
16 `"framework": null` matters. Vercel's detection looks for a `package.json` and,
17 finding none, will otherwise guess — and a wrong guess produces a build that
18 fails in a way that reads as sqzass's fault.
19
20 ## Preview deployments
21
22 Vercel exposes the preview host as `$VERCEL_URL`, without a scheme:
23
24 ```json
25 {
26 "buildCommand": "… && ./sqzass build --base-url \"https://$VERCEL_URL\""
27 }
28 ```
29
30 Same reasoning as everywhere else: internal links are root-absolute and work
31 regardless, but canonical, the sitemap and social tags are absolute and would
32 otherwise announce production from a preview.
33
34 ## Trailing slashes
35
36 sqzass writes `/start/index.html`, so `/start/` is the canonical form and every
37 link it generates uses it. Vercel's default `trailingSlash` behaviour redirects
38 between the two, which costs a hop on links written by hand as `/start`. Setting
39 `"trailingSlash": true` removes the hop.
40
41 This is a preference, not a requirement — the site is correct either way.
42
43 ## What this does not need
44
45 No serverless functions, no ISR, no edge config, no image optimisation.
46 sqzass has nothing to run at request time, so the parts of Vercel that
47 distinguish it from a file server are all inert here.
48
49 That is worth saying plainly: if Vercel is where your team already deploys,
50 this works. If you are choosing a host for a sqzass site, the reason to pick one
51 over another is not going to be its framework support.