NoSignups (FckSignups)
Deploy NoSignups: separate static assets, live catalogue data and submissions
Understand what the Vite build deploys, why the production catalogue can change independently, and when the optional submission Worker becomes a separate service.
What you will learn
- Static frontend, catalogue source and submission service are separate artifacts.
- A main-branch catalogue can change without a frontend deployment.
- A fork must review its identity and write destinations.
Before you start
- Basic JavaScript and JSON knowledge
- A harmless sample task and catalogue fixture
Explain the chapter boundary and verify it using the proposed fixture or review record.
Key takeaways
- Static frontend, catalogue source and submission service are separate artifacts.
- A main-branch catalogue can change without a frontend deployment.
- A fork must review its identity and write destinations.
Build the directory frontend as its own artifact
The root package builds with tsc && vite build. The inspected Vite configuration adds React support and injects WebSite structured data into the HTML; it does not configure server-side rendering. In an unchanged Vite setup, the generated dist directory is the static frontend artifact. Verify the actual output after a build rather than uploading source files or treating the development server as the deployment.
The repository also contains a separate cloudflare-worker directory. Its Worker accepts submission, report and suggestion routes and can create GitHub issues. This is not needed merely to read cards, but a fork with those forms enabled must decide where they submit. Disable or adapt write actions in a read-only deployment so a private test does not accidentally contact the original project’s service.
Decide whether catalogue updates should be independent
PROD_JSON_URL points to tools.json on the upstream main branch through raw.githubusercontent.com. Production loading goes directly to that URL before the embedded fallback. A frontend release can therefore display later catalogue edits without being rebuilt. This is convenient for freshness, but it also means that rolling back JavaScript does not necessarily restore the previous list of tools.
For a controlled fork, choose explicitly between a moving catalogue URL and a versioned or same-origin snapshot. Changing that behavior is a fork modification, not an existing configuration switch demonstrated by this article. Record the source commit, catalogue hash and deployment identifier together. Verify fallback behavior separately, because an available but old dataset should not be reported as a fresh remote response.
Treat branding, metadata and forms as deployment inputs
websiteSchema contains the name NoSignups and the canonical website URL nosignups.net. Copying the project to a new domain without checking this metadata can describe the wrong publisher. Inspect the HTML, JSON-LD, source links and form endpoints as part of deployment, and check the actual dependency engine requirements rather than inventing a minimum Node version from the README.
If you operate the Worker, keep GitHub credentials in the Worker’s secret store, never in Vite-exposed frontend variables. The checked-in configuration documents its secret names and compatibility date, but does not prove a working production service. Use a repository you control for integration tests and obtain explicit approval before creating any issue. No Worker was deployed and no upstream issue was submitted for this article.
Implementation steps
- 1
Review package scripts and install dependencies in the intended build environment.
- 2
Run the build and inspect dist plus injected metadata.
- 3
Choose and record a catalogue versioning policy.
- 4
Disable or configure submission endpoints before publishing a fork.
Copy-ready example
git clone https://github.com/BraveOPotato/FckSignups.git
cd FckSignups
git checkout 5c3da4a1934c7a4ce833ebafbeb500b6f52a4faf
npm install
npm run build
# Local inspection of the built artifact, not a production service.
npm run previewFrequently asked questions
Does a frontend rollback restore the catalogue?
Not if the deployed frontend still fetches the moving upstream main-branch JSON. Version the catalogue separately if rollback consistency matters.
Do I need Cloudflare to host the directory?
The inspected root application produces a Vite frontend. The repository’s Cloudflare Worker is a separate write-service concern, not the browser’s local filtering engine.
Sources
- README.mdSource checked 2026-09-07
- package.jsonSource checked 2026-09-07
- vite.config.mtsSource checked 2026-09-07
- src/hooks/useTools.tsSource checked 2026-09-07
- src/components/Home/Tools/Tools.tsxSource checked 2026-09-07
- src/components/Home/Tools/ToolCard/ToolCard.tsxSource checked 2026-09-07
- src/types/index.tsSource checked 2026-09-07
- src/constants/fallbackData.tsSource checked 2026-09-07
- src/data/schema.jsSource checked 2026-09-07
- cloudflare-worker/worker.tsSource checked 2026-09-07
- cloudflare-worker/urlHandlers/handleSubmitTool.tsSource checked 2026-09-07
- cloudflare-worker/utils.tsSource checked 2026-09-07