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
Fulgur public website showing the network identity, server entry point and current product surfaces.

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

  1. Visitor to localized website

    Player / visitor -> Fulgur Website

  2. Player to live map

    Player / visitor -> Live Map

  3. Website to product API

    Fulgur Website -> Product API

  4. Website to identity

    Fulgur Website -> OIDC Identity

  5. Services to Redis

    Product API -> Redis

  6. Services to PostgreSQL

    Product API -> PostgreSQL

  7. Services to player data

    Product API -> MySQL

  8. Services to object storage

    Product API -> Object Storage

  9. Map to authenticated session

    Live Map -> OIDC Identity

  10. Map to player history

    Live Map -> MySQL

  11. Backend production runtime

    Product API -> Docker + Kubernetes

  12. Website production runtime

    Fulgur Website -> Docker + Kubernetes

  13. 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

Photo

01 / 01

Fulgur website displayed on a large desktop monitor and a phone in a minimal dark studio.

A focused product view of the localized Fulgur website across desktop and mobile.

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.