Queue North Website is the modern rebuild of the Queue North Technologies business website.
The goal is to replace the current static early-2000s-style HTML/CSS/JS site with a polished 2026 business website that clearly presents Queue North as a trustworthy communications, contact center, networking, and managed support partner.
The site should feel:
- Bright and professional
- Modern but not flashy
- Business-first, not cyber/gaming/crypto
- Easy to navigate
- Clear about Queue North's 8x8 partnership and service expertise
- Optimized for consultation and support request conversion
## Target Stack
- **Vite** — build tool, not Next.js
- **React** — SPA frontend
- **React Router** — client-side routing
- **Tailwind CSS** — utility-first styling
- **shadcn/ui** — component primitives
- **Sonner** — toast notifications
- **TanStack Query** — server state management
- **Express** — backend API
- **better-sqlite3** — SQLite database
## Layout Direction
The design direction is a light-first B2B technology layout with strategic dark navy sections.
Primary structure:
1.**Hero**
- Dark navy section
- Clear headline and value proposition
- Primary CTA: `Request Consultation`
- Secondary CTA: `Explore Services`
- Trust chips: 8x8 Certified Partner, Veteran Owned, 25+ Years Experience, SMB to Enterprise
Patch versions increment for completed task batches after the full pipeline finishes. Dispatch a task batch, run it through the required agents, then push that completed batch once. Example: Docker task batch goes through Neo → Private Hudson → Bishop → Ripley, then pushes as `0.2.1`. Notes/tags should use the version number only.
Work is dispatched as task batches. A batch runs through the required agents, then Ripley pushes that completed batch once.
Example Docker batch:
```txt
Neo → Private Hudson → Bishop → Ripley
```
The whole Docker batch is one checkpoint: `0.2.1`.
Do not increment the patch version for each individual agent inside the same batch. Increment only after the full task batch finishes and is ready to push.
Notes, tags, and checkpoint labels should use only the version number, such as `0.2.1`.
The application can be containerized using Docker for consistent deployment across environments.
### Prerequisites
- Docker (v20+)
- Docker Compose (v2+)
### Quick Start
#### Using Docker Compose (Recommended)
```bash
# Build and start the container
npm run docker:compose:up
# View logs
npm run docker:compose:logs
# Stop the container
npm run docker:compose:down
```
#### Manual Docker Build
```bash
# Build the image
npm run docker:build
# Run the container
npm run docker:run
```
### Environment Variables
Set the following in the `.env` file (not included in image by default):
```env
NODE_ENV=production
SERVER_PORT=3001
```
### Data Persistence
SQLite database is persisted in the `./db` directory. Data will survive container restarts.
**Note on data persistence:**
The application uses Docker named volumes (`queuenorth-db` and `queuenorth-logs`) to persist data. Docker manages the ownership and permissions of these volumes automatically, so no manual setup is required.
If you prefer to use host bind mounts instead, ensure your host `./db` and `./logs` directories are owned by UID 1001:
```bash
mkdir -p ./db ./logs
sudo chown -R 1001:1001 ./db ./logs
```
If you encounter "unable to open database file" errors, verify the host directory is writable by the container's UID (1001) or use named volumes as shown above.
### Health Check
The container includes a health check at `/api/health`. A healthy container returns:
```json
{"status":"ok","timestamp":"2026-05-12T..."}
```
### Ports
- Backend API: `3001` (host) → `3001` (container)
### Build Optimization
The `.dockerignore` excludes:
-`node_modules` (reinstalled in container)
-`dist` (built in container)
-`db/` (mounted as volume)
-`.git`, logs, private docs
This ensures minimal image size and reproducible builds.
