Architecture

Every page is a React Server Component rendered on request (dynamic = "force-dynamic"), reading through a single Prisma client. Interactivity is confined to client-component islands — the gallery’s filter and sort, the size selector and order form, the map, the film player — and writes go through route handlers (public forms) or server actions (the admin).

Rendering on every request is a deliberate trade: an edit in the admin is live on the next page load with no revalidation logic, and the build never needs database access to render. The catalogue is small, so the cost — a database round trip per view — is acceptable.

All work lands through pull requests into main. GitHub Actions (.github/workflows/e2e.yml) runs on every pull request and every push to main; Vercel deploys main to production on merge.

• One build script everywhere. npm run build is prisma generate && prisma db push && vitest run && next build, in CI and on Vercel alike, so the unit suite gates production and not only pull requests.
• No preview deployments. vercel.json disables deploys for the feature/, fix/, docs/, chore/, perf/, test/ and claude/ prefixes, and its ignoreCommand skips any other non-production build. CI is the pre-merge gate; visual checks happen locally against a production build.
• Schema changes ship with the code. prisma db push runs on every build, so the column exists before the code that reads it is served. There is no migrations directory: changes must be additive or nullable, and anything destructive needs a hand-written plan.
• E2E cannot touch production. The Playwright suite creates, edits and deletes rows. e2e/db-guard.ts refuses to start unless DATABASE_URL points at a local host — added after a local run once edited the live catalogue.

Eight tables. Paintings and photographs share Product, distinguished by type. Other tables refer to a work by its id rather than a foreign key: a film can be published before its painting is in the catalogue and links itself up once the product exists, and analytics events outlive a deleted work.

• Catalogue images live in the repository under public/paintings and public/photographs, so the artwork is version-controlled. They are served through the next/image optimiser, resized per viewport. A new admin upload lives on Blob until it is committed the same way.
• Blur-up placeholders come from data/blurs.ts for committed images, or the per-product blurDataURL made at upload. The generated file is stripped of metadata, and a unit test fails the build if metadata returns — it once took the placeholder file from 46 KB to 200 KB without anyone noticing.
• Copyright metadata has two writers that agree: an exiftool script for committed files (EXIF, IPTC, XMP) and a pure-JS writer for uploads (EXIF, XMP). Both change metadata only, never pixel data; the notice itself is defined once, in lib/copyright.ts.
• Films stay on Blob as MP4s with the index at the front (faststart), so playback begins before the file has fully arrived. The page renders a still poster; no <video> element exists until the visitor presses play, so no film data is downloaded unless asked for.
• Share images come from /api/og-image, which composes a card with sharp from a work that is currently visible — a hard-coded image could name a work that has since been hidden.
• Old URLs from the previous Squarespace site (/home/p/<slug>) redirect permanently to works still for sale; the rest return 404 on purpose rather than landing somewhere misleading.

At the time of writing: about 440 unit and component tests (Vitest and Testing Library) and about 85 Playwright tests, one of them opt-in. Beyond ordinary behaviour tests, a set of guards turn whole classes of mistake into build failures. Most exist because the mistake happened once.

• Admin authentication is a single password (one user) exchanged for an iron-session cookie: encrypted, httpOnly, SameSite=Lax, Secure in production, eight hours. Every server action that changes data checks that session before doing anything.
• Login attempts are limited to five per fifteen minutes per client IP. The limiter is in memory and per instance, so it slows brute force rather than guaranteeing a global limit.
• Cron routes require the CRON_SECRET bearer token and return 401 without it.
• Public forms validate names and emails server-side, and all three carry a honeypot. The booking form also rejects a submission made faster than a person could type it, and the contact form one with no spaces in it. The site stores no payment details because it takes no payments.
• The forms can’t be used as a mail relay. Each one emails a confirmation to the address typed in, from the site’s own domain, so each is rate-limited in Postgres across every serverless instance: per client IP and form, per recipient address, and a daily total (lib/form-rate-limit.ts). The confirmations repeat nothing the visitor typed — not even their name — and the stored keys are HMACs, never raw IP or email addresses. Over the IP limit, nothing is sent; over the others, the artist still gets the enquiry and only the confirmation is held back.
• Analytics stores no IP address: location is the coarse country and city Vercel supplies, and visitors are counted by a random httpOnly cookie. Headless browsers and bots are dropped at ingest.
• Other people’s photographs are re-encoded to remove location metadata, credited as their owners asked, and removable from the edit form.
• Secrets live in Vercel environment variables. The repository carries only .env.local.example, with placeholder values.

What is in place, and what is not, stated plainly — including the things that haven’t been done.

Automated security tests

These run in CI on every pull request:

• Admin login rejects a wrong password, and locks out after five failed attempts (e2e/admin.spec.ts, e2e/zz-rate-limit.spec.ts).
• Admin pages redirect to the login page without a session.
• The order endpoint refuses a size the work isn’t sold in and a work that doesn’t exist; every form sends nothing once over its limit; and no confirmation repeats a submitted name or title (__tests__/form-email-abuse.test.ts).
• The order and contact endpoints reject requests with missing fields, accept honeypot submissions without sending anything, and the contact endpoint rejects a message with no spaces (e2e/api-validation.spec.ts).
• Collectors’ photos are re-encoded, never published with their location data, and never stamped with the artist’s copyright (unit tests).
• The E2E suite refuses to run against a database that isn’t local.
• Every form posts, so one sent before JavaScript loads keeps the visitor’s email and message out of the URL, and out of analytics (e2e/forms.spec.ts).

Automated scanning (DAST)

After the E2E suite passes, CI starts the same production build again and runs the OWASP ZAP baseline scan against it: a spider crawls the site (over a thousand URLs) and ZAP’s passive rules check every response — headers, cookies, the policy, caching, information leaks. It sends no attack payloads and never touches production. The ZAP image is pinned, so a new release can’t fail an unrelated pull request. Any finding fails the job unless .zap/rules.tsv records it as triaged, with the reason; the report is attached to the run.

Its first run found four things, and all four were fixed rather than accepted. The contact form, sent before JavaScript loaded, put the visitor’s email and message in the URL; every form now posts. Responses announced X-Powered-By: Next.js. And the cross-origin opener and resource policies were missing. What it still reports is accepted on the record: the policy is report-only for now, GA4’s script can’t carry a subresource-integrity hash because Google changes it, and Cross-Origin-Embedder-Policy would block the map and analytics for an isolation the site doesn’t need. The public forms carry no anti-CSRF token because they act for no one — there is no session for a forged request to ride — while the admin’s server actions reject a request from another origin, behind a SameSite cookie.

Dependencies

Dependabot opens grouped update PRs weekly for npm packages and monthly for GitHub Actions, and GitHub raises security alerts with automatic fix PRs; each one runs the full CI like any other change. Installs are reproducible — package-lock.json is committed and CI uses npm ci — and CI runs npm audit on production dependencies, failing on any critical advisory.

The audit is held at critical rather than high for one known exception: the Prisma CLI’s own dependencies, which no 7.x release fixes and which run only during the build, never when a visitor loads a page.

Not done yet

DDoS and traffic spikes

Vercel applies automatic DDoS mitigation and system-level traffic filtering to every request before it reaches the application, and Attack Mode can be switched on for the project during an attack — it challenges browsers while letting known good bots through. The repository defines no firewall rules of its own. Because pages render per request against a serverless database over HTTP, a spike turns into more function invocations and queries rather than exhausted connections.

Load testing

load/visitors.js is a k6 script that simulates visitors: each one loads the gallery, a painting, a photograph or the photo gallery, then the gift shop, map or films, pausing one to three seconds between pages the way a person does. It reads the works from the sitemap, so it follows the live catalogue. It makes read-only GET requests for pages alone — no forms, no admin, nothing written — and k6 runs no JavaScript, so analytics never sees it. It stops itself if more than 1% of requests fail or the 95th percentile passes three seconds, and it has no default target, so nobody runs it against production by accident.

Against production on 28 September 2026 it ramped to 50 simultaneous visitors over three and a half minutes, about 24 page renders a second at the peak, every one a function invocation with its Neon queries:

Response times stayed flat as the load rose, which says the ceiling is well above 50. How far above was not tested: the run is capped deliberately, because it runs against the live site.

HTTP security headers

Every response — pages, API routes, the admin — carries X-Frame-Options: DENY (no other site may frame the pages), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that switches off the camera, microphone, geolocation, payment and other features the site never uses, and Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy set to same-origin, so no other site gets a handle on its windows or can embed its images. Nothing announces the framework. They are set once, in lib/security-headers.ts, and checked by a unit test and by an E2E test that reads real responses. Strict-Transport-Security comes from Vercel, with a two-year max-age.

Content-Security-Policy

Nonce-based and strict. proxy.ts gives every page request a fresh nonce; a script runs only if it carries it, or was loaded by one that did ('strict-dynamic') — no 'unsafe-inline' for scripts and no host allowlist. Next.js stamps the nonce on its own scripts, and the GA4 tags take it from the layout. Nonces need every page rendered per request, which this site already does, so they cost nothing extra here. Each outside service is named once: analytics, the newsletter, the map tiles and iframe, stored images and films.

Two deliberate allowances. Styles allow inline, because React renders style attributes that nonces can’t cover. And the admin alone may use blob: workers and eval, for the converter that turns iPhone photos into JPEGs; the public site gets neither.

It is sent as report-only for now: violations are reported to /api/csp-report, aggregated into CspViolation (directive, blocked origin, page, count) and nothing is blocked. An E2E test loads every page, the signed-in admin and a playing film and fails on any violation; once real traffic is quiet too, one constant switches it to enforcing.

• No interactive transactions. The Neon HTTP adapter runs single statements, so the admin avoids batch operations: reordering is a loop of single updates, and the analytics prune is one deleteMany.
• Connection URL lives in prisma.config.ts (Prisma 7), which loads .env.local over .env the way Next.js does, and never overrides a variable already set — so an exported local DATABASE_URL always wins.
• Server-action body limit is raised to 4.5 MB, matching Vercel’s function request limit; images are downscaled in the browser to fit.
• Identity and theme are data. Whose site this is lives in data/siteConfig.ts and the brand colours in Tailwind @theme tokens, which is what makes the repository a template: a second artist forks it and follows FORKING.md.
• Locally, .env points at the production database, so anything that writes is run against a throwaway Postgres and a production build.

• Daily catalogue backup. A cron writes a JSON snapshot of the Product table to Blob (backups/catalog-YYYY-MM-DD.json) and deletes snapshots older than seven days. npm run db:export takes one by hand.
• The artwork is in git. Committed catalogue images are versioned with the code; films are uploaded from their local source files by scripts/publish-films.ts.
• Destructive scripts archive first and default to a dry run. The Blob pruner checks every product, film and Instagram post for references before deleting, and archives each file it removes; the analytics purge writes the rows it will delete to a file named to the second, and refuses to overwrite an earlier one.
• Not in the daily backup: films, the Instagram queue and analytics. Films can be re-uploaded from their source files; the other two are operational data.

app/
  page.tsx · HomeClient.tsx        gallery (server page + client filter/sort)
  products/[id]  photographs/[id]  a work: sizes, order form, JSON-LD, room view
  locations/  making-of/           map of where works were made · films
  gift-shop/                       calendar, card and postcard pack builders
  about/  faq/  contact/  book/    static and form pages
  for-artists/  architecture/      the pitch · this page
  admin/                           CMS, Instagram queue, analytics dashboard
  actions/                         server actions: admin, instagram, analytics
  api/                             buy · contact · book · track · og-image · cron/*
  home/p/[slug]/                   legacy Squarespace URL redirects
  sitemap.ts · robots.ts           generated from siteConfig
proxy.ts                           per-request CSP nonce for every page
components/                        Navigation, ProductCard, GalleryGrid,
                                   BuyNowButton, MakingOfVideo, LocationMap, …
lib/
  db.ts                            Prisma singleton; adapter by URL
  csp.ts · csp-report.ts           the policy · parsing violation reports
  session.ts · rate-limit.ts       admin session · login limiter
  order.ts                         what an order is: server-side titles and prices
  form-rate-limit.ts               Postgres-backed limits for the public forms
  analytics.ts                     UA parsing, bot and host filters
  instagram.ts                     caption drafting, price ranges, scheduling
  instagram-publish.ts             two-step Graph API publish
  blob-cleanup.ts                  reference counting before delete
  home-photo.ts                    re-encode collectors' photos (strips GPS)
  image-copyright.ts               stamp the artist's notice on uploads
  availability.ts · json-ld.ts     sold-out rules · structured data
data/                              siteConfig, price table, seed catalogue, blurs
prisma/                            schema.prisma · seed.ts
scripts/                           films, mockups, blurs, copyright, backups,
                                   Blob pruner, analytics purge
__tests__/                         Vitest unit, component and source-scan tests
e2e/                               Playwright specs, axe scans, db-guard
.github/workflows/e2e.yml          audit, build, E2E + ZAP scan on every PR and push to main
.zap/rules.tsv                     ZAP findings triaged as accepted, with reasons
load/visitors.js                   k6 load test: simulated visitors, read-only
.github/dependabot.yml             weekly npm and monthly Actions updates
vercel.json                        branch deploy rules · crons