Website and launcher auth channels
Custom solutions
A custom platform for Minecraft servers, players and operations
A connected ecosystem spanning the public website, launcher authentication, player accounts, server and build management, per-user access, content, internal currency, donations and admin audit tooling.
Results
The project at a glance.
Fuse1 runs as one system: the website and launcher share identity and sessions; every player record carries balance, login history and server restrictions; the team manages accounts, builds, content, orders and sensitive actions through one auditable admin console.
Server modes with per-player access rules
Connected data and operations modules
01 / Challenge
A platform, not a collection of pages
The public website is only the front door. Behind it, Fuse1 connects the launcher, user accounts, sessions, game modes, builds, internal currency, news, donation orders and support and security processes through one shared product core.
02 / Approach
Player identity controls access across the system
Registration and login work across the website and launcher through shared sessions and bearer tokens. Each player has a balance, donation and login history, security state, role and a server-specific access list. Administrators can suspend an entire account or restrict individual modes, and the launcher receives those rules directly.
03 / Result
One console for day-to-day operations
The admin system combines player search, coin adjustments, roles, bans and session revocation, password recovery, build versioning and publication, blog and news management, donation confirmation with coin crediting and rollback, project statistics and a complete administrator action log.
04
Inside the product
One player identity connects the entire ecosystem.
Fuse1 was designed around a single operational model rather than separate website features. The same player moves from the public experience into the launcher, receives account-specific server permissions, uses the internal economy and remains visible to the team through one administrative record.
System map
Nine connected modules. One source of operational truth.
Each module owns a clear responsibility, but they share users, permissions and history. That connection is what turns the interface into a platform.
Public experience
Project discovery, news, server modes, builds, onboarding and launcher download.
Identity & sessions
Registration and login shared by the website and launcher through channel-specific sessions.
Player account
Profile, balance, donation history, login history and account security in one place.
Server access
Six game modes with restrictions applied to an individual player and returned to the launcher.
Build management
Versions, Minecraft compatibility, status, features and publication state managed by the team.
Content system
News and updates with categories, publication controls and search metadata.
Internal economy
Player coin balances and controlled administrative adjustments with a recorded reason.
Orders & donations
Catalog-validated orders, payment status and controlled coin crediting or rollback.
Operations & audit
Roles, bans, recovery, project statistics and a trace of sensitive administrator actions.
Two sides of one system
The player journey and the operating workflow stay synchronized.
A player action changes the same data the team sees and manages. There is no separate admin copy of the product state and no disconnected launcher account.
Player side
From registration to the right server access
The product carries identity, permissions and account history across every player touchpoint.
- 01Create one account
- 02Sign in on site or launcher
- 03Receive personal access rules
- 04Choose an available mode or build
- 05Manage balance, history and security
Team side
From overview to a controlled operation
The administrative layer connects everyday publishing with sensitive account and economy actions.
- 01See project status
- 02Find a player and review context
- 03Change role or server access
- 04Publish builds and content
- 05Resolve orders and review the audit trail
Security and control
Sensitive actions are part of the product architecture.
Security was treated as an operating requirement: identity must be protected, access must be reversible and administrative changes must remain attributable.
Protected credentials
Passwords use a modern memory-hard hash with an individual salt and timing-safe verification.
Controlled sessions
Website and launcher sessions are separated by source and can be revoked when security state changes.
Granular access
The team can suspend an account or restrict individual server modes without rebuilding the player profile.
Auditable operations
Role, balance, access and order changes leave an administrative record instead of becoming invisible edits.
What was delivered
Not a website with extras. A shared operating layer for the project.
The public site, launcher access, player records, server permissions, builds, content, economy and administration were shaped as one product. Donations are an important subsystem, but their value comes from being connected to identity, balance, fulfilment and audit rather than existing as an isolated checkout.
Selected details
The work in context.
Selected moments from the process, the working system and the final delivery.
Start a project
Have a similar challenge?
Marketing strategy
