Work in Progress - This project is under active development.
Hackathon management system with Go backend and React frontend.
There are two ways to run the dev environment, depending on how you want to handle SuperTokens auth:
Uses a managed SuperTokens instance. Requires SUPERTOKENS_CONNECTION_URI and SUPERTOKENS_API_KEY in your .env file.
docker compose -f docker-compose.dev.yml up --build| Service | URL |
|---|---|
| Frontend | http://localhost:3000 |
| Backend API | http://localhost:8080/v1 |
| PostgreSQL | localhost:5432 |
| Swagger Docs | http://localhost:8080/v1/swagger/ |
| Debug Vars | http://localhost:8080/v1/debug/vars |
Runs a self-hosted SuperTokens instance in Docker. No API key needed.
docker compose -f docker-compose.local-st.yml up --build| Service | URL |
|---|---|
| Frontend | http://localhost:3000 |
| Backend API | http://localhost:8080/v1 |
| SuperTokens | localhost:3567 |
| PostgreSQL | localhost:5432 |
| Swagger Docs | http://localhost:8080/v1/swagger/ |
| Debug Vars | http://localhost:8080/v1/debug/vars |
The backend runs database migrations automatically on startup. Both the frontend and backend support hot reload via mounted volumes.
Backend: Go, Chi, PostgreSQL, SuperTokens, SendGrid
Frontend: React 19, Vite, TypeScript, Tailwind CSS, shadcn/ui
Deployment: GCP (GCR, GCS), multi-stage Docker (scratch), Neon DB
The production image starts the API but does not run database migrations. Run
task migrate-up from a trusted migration job or workstation with DB_ADDR
configured before the first API deployment and before deploying releases that
include new migrations.
On a fresh database, application submissions and the points system are disabled until a super admin enables them. Admin schedule, sponsor, and FAQ editing permissions remain enabled by default.
The Super Admin full reset is a destructive transition between hackathon cycles. Back up or export anything that must be retained before running it. It deletes applications and reviews, the walk-in queue, scans and scan stats, custom scan types, schedule and notification history, sponsors, FAQs, and the old event identity/dates. Applications and the points UI are left disabled until the next event is configured.
User accounts and roles, push-notification opt-ins, contact/sender settings, the application schema, review count, admin permissions, and meal-group names carry forward intentionally.
New resumes use the GCS object prefix
hackathons/<sanitized-hackathon-name>/resumes/<user-id>/<random-id>.pdf.
Include the year in each event's configured name to get a distinct, readable
prefix per cycle. GCS prefixes are virtual folders inside GCS_BUCKET_NAME,
not separate buckets. Resetting applications queues cleanup of both this layout
and the legacy resumes/ layout, including orphaned uploads. The API service
account therefore needs permission to list and delete objects in addition to
creating and reading them.
The scan page can offer an Apple Wallet pass when it is opened as an installed iPhone PWA. Pass generation is disabled by default. To enable it, create a Pass Type ID and signing certificate in the Apple Developer portal, then configure the backend with:
APPLE_WALLET_ENABLED=true
APPLE_WALLET_PASS_TYPE_IDENTIFIER=pass.com.example.hackutd
APPLE_WALLET_TEAM_IDENTIFIER=YOURTEAMID
APPLE_WALLET_CERTIFICATE_BASE64=<base64-encoded pass certificate in PEM or DER format>
APPLE_WALLET_PRIVATE_KEY_BASE64=<base64-encoded unencrypted PKCS#8, PKCS#1, or EC private key>
APPLE_WALLET_WWDR_CERTIFICATE_BASE64=<base64-encoded Apple WWDR certificate in PEM or DER format>Optional values are APPLE_WALLET_ORGANIZATION_NAME,
APPLE_WALLET_DESCRIPTION, and APPLE_WALLET_ICON_PATH. The default icon is
the PWA icon. Keep the certificate and private key in your deployment's secret
manager; never commit them to the repository. Apple documents the certificate
and bundle requirements in Building a Pass.