Product
Fulgur
A live online game platform and community ecosystem spanning product development, web services, infrastructure, community operations and continued growth.
- Role
- Founder & Full-stack Engineer
- Period
- 2017—present
- Categories
- FrontendBackendInfrastructure
- Stack
- Next.jsTypeScriptNestJSFastifyPostgreSQLRedisMySQLDockerKubernetes

Key metrics
- New unique players
- 21K+/year
- New platform player identities in the private rolling 12-month production aggregate.
- Threshold rounded down to the nearest thousand; players, not website visitors.
- Production services
- 27
- Active deployable services in the production service inventory.
- Current snapshot; development, test services and replicas are excluded.
Overview
Fulgur launched in 2017 as a modded multiplayer game server and evolved as the audience, gameplay and product direction changed. It has grown into an online game platform that combines persistent playable worlds with a localized public website, live map, news, account-aware surfaces and community channels.
The platform is developed as a long-running product rather than a single delivery. My work covers product and engineering decisions, web and backend systems, infrastructure, content, community operations and continued development.
Challenge
A long-running game community cannot be treated like a greenfield launch. Platform changes, migrations and new player-facing features have to coexist with an active product and with the expectations built up since 2017.
The public experience also crosses several boundaries: localized content, server status and player data, authentication, a live map, multiple data stores and production services. Those boundaries need to remain understandable and recoverable without exposing private topology or credentials.
Solution
I shaped the public website as a localized Next.js player hub for discovery, server connection, project information, news, rules, support surfaces and the live map. It gives visitors a coherent product entry point while the game servers and community channels remain distinct operational surfaces.
Behind it, typed NestJS and Fastify services connect Redis, PostgreSQL, MySQL and object storage where each is appropriate. The backend migration runs alongside the legacy service and uses domain feature flags, health and readiness checks, contract comparison, staged traffic cutover and an explicit rollback path before old responsibilities are retired.
Responsibilities
- Set the product direction and evolve Fulgur from its original modded-server format into the current network.
- Design and build the localized Next.js website and its player-facing flows.
- Build and migrate backend services for server data, players, announcements and synchronization.
- Connect identity, Redis-backed sessions, player history and the public live-map experience.
- Package and operate services with Docker and Kubernetes while owning rollout and rollback decisions.
- Create content, run community operations and connect engineering work with promotion and growth.
Architecture
Interface
Player / visitor
Fulgur Website
Live Map
Services
Product API
OIDC Identity
Data
Redis
PostgreSQL
MySQL
Object Storage
Infrastructure
Docker + Kubernetes
Visitor to localized website
Player / visitor -> Fulgur Website
Player to live map
Player / visitor -> Live Map
Website to product API
Fulgur Website -> Product API
Website to identity
Fulgur Website -> OIDC Identity
Services to Redis
Product API -> Redis
Services to PostgreSQL
Product API -> PostgreSQL
Services to player data
Product API -> MySQL
Services to object storage
Product API -> Object Storage
Map to authenticated session
Live Map -> OIDC Identity
Map to player history
Live Map -> MySQL
Backend production runtime
Product API -> Docker + Kubernetes
Website production runtime
Fulgur Website -> Docker + Kubernetes
Map production runtime
Live Map -> Docker + Kubernetes
Technical decisions
Treat continuity as a product constraint
- Problem
- Fulgur needed to change direction and technology without discarding the community, history and operational knowledge accumulated since 2017.
- Decision
- Evolve the product in stages, keeping stable public entry points while replacing individual systems behind them.
- Reason
- Incremental change keeps product decisions grounded in a live community and gives each technical migration a clear boundary.
- Trade-off
- Old and new responsibilities can overlap for longer, so ownership and retirement criteria must stay explicit.
Migrate the backend through a reversible cutover
- Problem
- Replacing a legacy backend in one step would combine contract risk, deployment risk and data-integration risk.
- Decision
- Run the typed NestJS and Fastify service in parallel, enable domains separately through feature flags and move traffic in monitored stages.
- Reason
- Contract checks, health endpoints and a direct rollback path make the migration observable and reversible.
- Trade-off
- Parallel operation adds temporary deployment and compatibility work.
Keep public access separate from private source
- Problem
- Visitors should be able to inspect the real product, but repository links and internal infrastructure details are not intended for publication.
- Decision
- Publish the live website, map and sanitized architecture while modelling the project as source-closed.
- Reason
- The project page can show real product and engineering responsibility without exposing private code or sensitive topology.
- Trade-off
- Some implementation details must be explained through verified summaries rather than source links.
Media
Gallery
Outcomes
- Fulgur remains an actively developed platform with a public network, website, live map and community surfaces.
- The localized website brings server discovery, project information, news and player resources into one consistent entry point.
- The backend transition has a staged cutover and rollback model instead of depending on a single irreversible release.
Verified highlights
- The current public website supports English and Russian and links the playable network, live map and community channels.
- The backend migration uses parallel operation, domain feature flags, contract checks, health/readiness endpoints and staged traffic cutover.
Learnings
- Long-term ownership means treating software, operations, content and community trust as parts of the same product.
- Migration safety improves when rollback, compatibility and observability are designed before traffic moves.