When I started building WICKET, my goal was simple but ambitious:
> To create a self-hosted, open-source authentication system that's as powerful as proprietary SaaS providers like Clerk or Auth0, but with full control, transparency, and scalability.
For that, every technology I picked had to pass one main filter: Will this scale well when used by hundreds of thousands of users?
Technology Stack Overview
Frontend: Next.js 15 with TypeScript
I chose Next.js 15 because it's currently one of the most scalable React-based frameworks. Its hybrid rendering model (SSG, SSR, ISR) makes it ideal for authentication UIs that need both speed and dynamic personalization. When a user logs in, you want the page to update instantly while still being SEO-friendly for public routes.
Why TypeScript? Strong typing prevents runtime errors and improves developer productivity, especially for large-scale, long-term projects like WICKET. Since authentication systems handle sensitive data, type safety also reduces accidental bugs in security-critical code.
Next.js can handle huge amounts of traffic with incremental builds and edge rendering. This ensures that WICKET's frontend won't become a bottleneck even when deployed at scale.
Alternatives I Considered:
- React with Vite: Great for speed, but lacks the advanced ecosystem and flexibility of Next.js.
- Remix: Promising, but still maturing compared to Next.js.
Backend: Fastify with TypeScript
For the backend, Fastify was the obvious choice. While Express.js dominates the Node.js ecosystem, Fastify is much faster and lighter, perfect for building APIs that need to handle millions of authentication requests per day.
Why TypeScript here too? To keep the whole project consistent, strongly typed, and easy to scale with contributors.
Fastify's plugin system and low overhead make it highly suitable for microservices. WICKET can grow from a single service to a cluster of distributed services without major rewrites.
Alternatives I Considered:
- Express.js: Popular and battle-tested, but slower and less optimized for high throughput.
- NestJS: Great for large-scale structure, but too heavy for my use case where lightweight and speed matter more.
Database: PostgreSQL with Prisma
Authentication systems need a reliable, ACID-compliant database. I picked PostgreSQL because it's robust, scalable, and has native JSON support for flexible data structures. It's also open-source, which aligns with WICKET's philosophy.
On top of that, I use Prisma ORM for type-safe queries, schema management, and developer productivity. It's modern, integrates seamlessly with TypeScript, and makes scaling schemas over time much easier.
Postgres can handle complex queries, high write loads, and horizontal scaling with read replicas. With Prisma's migration tools, schema evolution in large deployments becomes painless.
Alternatives I Considered:
- MySQL: Reliable but not as feature-rich as Postgres.
- MariaDB: Popular in many servers, but Postgres has better long-term scaling features.
- MongoDB: Great for flexibility, but authentication data often needs strong relational guarantees.
Caching & Session Management: Valkey
When you're dealing with login tokens, OTPs, rate-limiting, and session storage, performance is everything. For this, I chose Valkey, the open-source fork of Redis maintained by the Linux Foundation.
It provides in-memory storage with microsecond latency, making it perfect for caching user sessions, managing distributed tokens, and ensuring login requests stay lightning fast.
Valkey can be clustered and scaled horizontally across nodes, making it reliable for high-availability setups. This ensures WICKET can handle sudden traffic spikes without bringing down the database.
Alternatives I Considered:
- Redis (official): Great, but recent licensing changes raised concerns for long-term open-source projects.
- Memcached: Fast, but less feature-rich compared to Redis/Valkey.
Validation: Zod
Security begins with input validation. I use Zod because it's type-safe, pairs beautifully with TypeScript, and ensures that every input (from forms to API requests) is validated at runtime.
Zod scales at the developer experience level when many contributors join the project, consistent validation rules reduce bugs and keep the codebase safe.
Alternatives I Considered:
- Joi: Powerful, but less TypeScript-friendly.
- Yup: Good for frontend forms, but weaker compared to Zod's ecosystem.
Containerization: Docker
Finally, WICKET had to be easy to deploy and scale anywhere from a developer's laptop to a global cloud cluster. Docker was the natural choice.
With each service containerized, WICKET can run consistently across environments. This also opens doors for Kubernetes orchestration in the future, making large-scale deployments easier for teams.
Docker ensures that no matter how many instances you spin up, the environment is consistent. Combined with orchestration, it makes horizontal scaling straightforward.
Alternatives I Considered:
- Podman: Great but less widely adopted.
- Direct Bare-Metal Setup: Not portable, harder to maintain.
Final Thoughts
Each choice I made for WICKET was driven by this single philosophy. The result? A truly open-source, self-hosted authentication system that doesn't compromise on scalability.