Back to Projects

Elaria

Elaria project visual
Role
Full-Stack Developer
Period
2025 - Present
Type
Website

Overview

Elaria started as a custom MMORPG Minecraft website concept, but I did not want it to stop at a nice landing page. I used it to build a complete player-facing platform: accounts, protected profile data, a dashboard, staff roles, public rules, and a small admin area ~ all inside the same ice-blue visual direction.

What I worked on

I designed and built the site from the first interface ideas through to the account flow and database structure. That means the UI, responsive layouts, authentication, profile creation, dashboard state, role handling, public staff directory, and the admin-only role tools are all part of the same project.

The problem

The main challenge was making the playful Minecraft design work with real account data. A player should be able to register and manage their own profile without seeing someone else’s data, while staff information can still be shown publicly and role controls stay restricted to the right account.

Building the platform

Starting with the player experience

I began with the feeling of the site instead of a generic dashboard. Elaria uses a cold, ice-blue palette, snow details, a custom cursor, soft animation, sound feedback, and rounded bento panels. The goal was to make every page feel like it belongs to the same fantasy Minecraft world, including the account pages that are usually the least interesting part of a site.

Turning a form into a real account system

The login and register screens are connected to Supabase Auth rather than pretending to work. Email confirmation, sign-in, sign-out, password updates, and redirect behavior are handled through the auth flow. A signed-in player is sent to their dashboard instead of being asked to log in again.

Profiles are separate from authentication

Passwords belong to Supabase Auth. The public.profiles table stores the player-facing data instead: Minecraft username, display name, role, last seen, and profile views. A PostgreSQL trigger creates the profile automatically when an account is registered, so the auth account and Minecraft profile stay connected without a manual setup step.

Keeping player data private

I used Row Level Security so an authenticated player can read their own profile, but not browse everyone else’s information. The public staff page is the exception: it only reads usernames and staff roles for Admin, Mod, and Helper accounts. Normal member profiles stay private.

A dashboard with an actual purpose

The dashboard shows the Minecraft username, skin head, role, account activity, and password controls in small bento sections instead of one oversized settings page. It also gives my admin account a separate path to manage staff roles, so role assignment is not mixed into a normal player dashboard.

What I wanted to prove with it

Elaria is still a concept project, but the website is real work. It let me practice the part of web development that comes after making a page look good: shaping the data model, protecting it, handling account states, and keeping all of that inside a design that still feels personal.

Systems I built

  • Responsive ice-blue UI with custom interaction details
  • Email registration, confirmation, login, logout, and password updates
  • Supabase Auth connected to a PostgreSQL profiles table
  • Automatic profile creation through a database trigger
  • Private player profiles protected with Row Level Security
  • Player dashboard with Minecraft skin head and account activity
  • Admin-only role management for Admin, Mod, and Helper
  • Public Rules and Staff pages powered by the same profile data

Tech stack

  • Astro
  • TypeScript
  • CSS
  • Supabase Auth
  • Supabase PostgreSQL
  • Row Level Security
  • SQL Triggers and Functions
  • Vercel
  • Minecraft Skin Head API