Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/VasquezRivero92/HabboCafe/llms.txt

Use this file to discover all available pages before exploring further.

HADOS is a client-side single-page application — the entire app compiles down to static HTML, CSS, and JavaScript files in the dist/ directory. There is no application server required; all backend logic is handled by Firebase. This makes deployment straightforward: build the assets, then serve them from any static host or the included server.js.

​
Building for production

1

Install dependencies

If you have not already done so, install the project’s npm dependencies:
npm install
2

Configure environment variables

Ensure your Firebase credentials are available as VITE_ prefixed environment variables (either in .env.local for manual builds or as platform secrets for CI). See the Environment Variables guide for the full variable list.
3

Run the production build

npm run build
This command runs in two phases:
  1. tsc -b — TypeScript compiles the project using the composite build references in tsconfig.json, checking tsconfig.app.json and tsconfig.node.json. Any type errors will abort the build here.
  2. vite build — Vite bundles the React application with tree-shaking and minification, writing the output to dist/.
The resulting dist/ directory contains everything needed to serve the app — no Node.js runtime is required at serve time unless you use server.js.
4

Verify the build locally

Before deploying, confirm the production bundle works correctly:
npm run preview
This uses Vite’s built-in preview server to serve dist/ on http://localhost:4173.
5

Deploy to your chosen host

Upload the dist/ directory to your hosting platform, or start server.js on your server. See the sections below for platform-specific instructions.

​
Serving with server.js

The repository includes server.js — a dependency-free Node.js HTTP server that serves the dist/ build with SPA routing support. Use it on any server where you can run Node.js directly. 
node server.js
Key behaviours:
  • Serves from dist/ — if dist/index.html exists the server roots itself there; otherwise it falls back to the project root.
  • SPA fallback — requests for paths that do not match a physical file receive index.html, so client-side routes like /tournament/123 work correctly after a hard refresh.
  • server.js protection — direct requests to /server.js are rejected with a 403 Access Denied response.
  • MIME types — .html, .css, .js, .json, .png, .jpg, .gif, .svg, and .ico are served with the correct Content-Type headers.

​
Configuring the port

The server reads its port from environment variables in this order: 
PORT=8080 node server.js          # most cloud platforms
SERVER_PORT=8080 node server.js   # fallback variable name
node server.js                     # defaults to port 8080

​
Alternative hosting options

Because the build output is pure static files, HADOS can be deployed to any CDN-backed static host without server.js. The SPA rewrite rule must be configured on whichever host you choose.

Firebase Hosting

The natural choice — your app and its backend live in the same Firebase project. Firebase Hosting provides a global CDN, automatic HTTPS, and a one-command deploy via the Firebase CLI.

Vercel / Netlify / Cloudflare Pages

All three platforms auto-detect Vite projects, run npm run build, and deploy dist/ automatically. Configure the SPA rewrite so all routes return index.html.

​
Firebase Hosting

Install the Firebase CLI and initialise hosting in the project root: 
npm install -g firebase-tools
firebase login
firebase init hosting
Use the following firebase.json to configure the build directory and enable the SPA rewrite: 
{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}
Deploy with: 
npm run build
firebase deploy --only hosting

​
Firestore security rules

Before HADOS goes live you must replace the default Firestore security rules with rules that restrict access to authenticated users. By default, databases created in test mode allow any read or write for 30 days — this is not safe for production.
A Firestore database in test mode is publicly writable — anyone with your Firebase project ID can read, overwrite, or delete all tournament data without authentication. Always set proper security rules before sharing the app URL.
Open Firestore Database → Rules in the Firebase console and replace the default rules with the following minimal ruleset: 
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Organizer user profiles — readable by the owning user only
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }

    // Tournament groups — any authenticated user can read;
    // only authenticated users can create or modify
    match /dados/{dadoId} {
      allow read: if request.auth != null;
      allow create, update, delete: if request.auth != null;
    }
  }
}
These rules are a starting point. For a multi-organizer setup you may want to store an organizerId field on each dados document and restrict update and delete to request.auth.uid == resource.data.organizerId, ensuring organizers can only modify their own tournaments.
Publish the rules from the console or via the CLI: 
firebase deploy --only firestore:rules

Build docs developers (and LLMs) love

Get started for freeTalk to us