I built an open-source platform that launches internal hackathons in minutes, not weeks. Three commands deploy it. You get registration, team formation, presentation tracking, an admin dashboard and an audit log of every action.
It’s self-hosted and MIT licensed, built with Go, the Buffalo framework and PostgreSQL. Below is what it does, how to deploy it, and how it’s built.
Table of Contents
- What you get
- How to deploy it
- How an event runs on it
- Why Go, Buffalo and PostgreSQL
- How the code and data are organized
- How security is handled
- How to work on the code
- What’s on the roadmap
- What building it taught me
- FAQ
- Links
What you get
Internal hackathons drive innovation, team building and employee engagement. Running them takes more than spreadsheets and email chains. I’d seen firsthand the challenges companies face organizing these events, so I built a self-hosted platform for them.
The platform has two roles:
- Owners have full administrative access. They manage users, create hackathons and view audit logs.
- Hackers are participants. They create projects, join teams and upload presentations.
That simple model covers most organizational structures without over-engineering.
Team management is one of the most complex features. The platform supports:
- One project per user per hackathon, enforced via a unique constraint.
- Users joining projects to form cross-functional teams.
- Projects opting in to present, with order management.
- Teams uploading project materials, stored securely with metadata.
The data model keeps referential integrity while allowing flexible team compositions.
The admin interface gives organizers one place to see:
- User statistics and management
- Hackathon overview with status tracking
- Project monitoring across all events
- Audit log viewer with filtering
- Presentation dashboard for event day
- Password policy configuration
That single view reduces operational overhead for hackathon organizers.
How to deploy it
The platform is on GitHub and deploys in minutes:
git clone https://github.com/arxdsilva/hackathon
cd hackathon
make docker-up
It supports two deployment strategies. Docker Compose is a single command with all dependencies:
docker-compose up
Or compile it to a single static binary:
buffalo build
./bin/app
Schema changes are version-controlled with Buffalo’s migration system. The Dockerfile uses multi-stage builds, which reduces the final image size while keeping every necessary dependency.
The repository has the full documentation, setup guides and contribution guidelines.
How an event runs on it
Several usage patterns emerged through testing and feedback:
- Pre-hackathon: admins create the event, and participants register and form preliminary teams.
- During the hackathon: teams finalize projects, upload materials and opt in for presentations.
- Presentation day: the admin dashboard shows the order and status of each presenting team.
- Post-event: audit logs give insight into participation and engagement.
The platform handles the full lifecycle, from event creation to post-event analysis.
Why Go, Buffalo and PostgreSQL
I chose this stack for four reasons:
- Go has an excellent concurrency model and low resource consumption.
- Buffalo gives a Rails-like developer experience, with hot reload and generators.
- PostgreSQL’s ACID compliance protects the audit log and data integrity.
- Self-hosting lets companies keep complete control over their IP and project submissions.
Go is known for microservices and CLI tools. Buffalo brings a full-featured web framework to the ecosystem:
- Integrated asset pipeline with webpack
- Database migrations and ORM (Pop)
- Session management and CSRF protection
- HTML templating with Plush
- Hot reload during development
The platform needs both API endpoints and a rich admin interface, so Buffalo was the right fit.
How the code and data are organized
A repository pattern separates business logic from data access:
type HackathonRepository interface {
Create(h *models.Hackathon) error
Update(h *models.Hackathon) error
FindByID(id uuid.UUID) (*models.Hackathon, error)
List(page, perPage int) ([]models.Hackathon, error)
Delete(id uuid.UUID) error
}
This abstraction makes testing straightforward. It also keeps the codebase maintainable as requirements evolve.
Every user action is logged with timestamp, IP address and user agent. That creates an immutable audit trail for compliance and debugging.
Files are stored directly in PostgreSQL as binary data. This approach has trade-offs. It simplifies deployment, since there’s no S3 configuration, and it keeps file writes transactionally consistent.
How security is handled
Security is built into every layer from the start.
Authentication:
- bcrypt password hashing with per-user salts
- Session-based authentication with secure cookies
- CSRF token validation on all state-changing operations
Authorization:
- Middleware-based role checking
- Resource ownership validation
- Protected admin routes
Audit trail:
- Logging of all user actions
- IP address and user agent tracking
- Immutable audit log for forensics
Password policies:
- Configurable minimum length
- Uppercase, number and special character requirements
- Forced password reset for new accounts
How to work on the code
I invested heavily in developer experience. The Makefile has 25+ commands, including:
make dev # Start with hot reload
make test # Run test suite
make coverage # Generate coverage report
make docker-up # Launch with Docker Compose
make db-migrate # Run migrations
make db-reset # Reset database
make lint # Run linters
New contributors can be productive in minutes.
The project is open source under the MIT license, hosted on GitHub with:
- A README with a quick start guide
- A CI/CD pipeline with automated tests
- Contribution guidelines
- Issue templates for bugs and feature requests
- Active maintenance and updates
My goal is to help other developers and organizations run better hackathons without reinventing the wheel.
What’s on the roadmap
Several enhancements are planned:
- A voting system so participants can vote on projects
- A judges dashboard for scoring presentations
- Email notifications with automated reminders and updates
- Advanced analytics on participation trends and engagement
- OAuth integration for SSO with common providers
What building it taught me
Building this with Go and Buffalo taught me five lessons:
- Framework choice matters. Buffalo gave the right balance of structure and flexibility for this use case.
- Security is continuous. Every feature needed security considerations from the start.
- Developer experience pays off. Time spent on tooling and documentation speeds up development.
- Database design is critical. Proper constraints and indexes prevent bugs and improve performance.
- Audit everything. Logging is invaluable for debugging and compliance.
If you run hackathons at your organization, give it a try and let me know how it works for you.
FAQ
How do I deploy the hackathon platform?
Clone the repository and run make docker-up. You can also run docker-compose up, or compile a single static binary with buffalo build.
What roles does the platform support?
Two. Owners manage users, create hackathons and view audit logs. Hackers create projects, join teams and upload presentations.
Where are uploaded files stored?
Directly in PostgreSQL as binary data. That avoids S3 configuration and keeps writes transactionally consistent, with some trade-offs.
Is the hackathon platform free?
Yes. It’s open source under the MIT license and self-hosted, so companies keep control over their IP and project submissions.
Links
- GitHub Repository
- Buffalo Framework
- Live Demo (Coming Soon)
Questions or feedback? Schedule a call or reach out on LinkedIn or X.