The four codebases

TogoActive is four applications in four repositories, arranged as two pairs. Each pair is an API and a frontend; the two pairs share one database.

Repository	What it is	Runs on	Served at
togoparts/tga-v3-admin-web	Admin panel — React + Vite SPA	128.199.72.46	v3.togoactive.com
togoparts/tga-v3-admin-api	Admin API — Laravel	128.199.72.46	v3.togoactive.com/api
togoparts/tga-v3-wl-web	Public event sites — Next.js	178.128.113.107	every customer domain
togoparts/tga-v3-wl-api	Public API — Laravel	178.128.113.107	wl-api.togoparts.com

"WL" is white-label: one deployment that serves every customer's event under their own domain.

There is a fifth system, and it is not in this list

The legacy app at /var/www/togoactive on the WL host runs the cron fleet — Strava sync, leaderboard stages, rank stored procedures and achievement awards — against the same shared database, plus the Togoparts database. It owns the activity pipeline outright; the four applications above only read its results.

It is not one of the four because nobody develops features in it, but editing it is deploying to production. See Legacy app and TGP.

How they fit together

The database is the integration. There is no API call between the admin side and the WL side for ordinary data. An organiser saves a setting through the admin API, it lands in a shared table, and the WL side reads it on the next request. That is the whole contract.

The one place the two sides do talk directly is the deploy agent, which the admin calls when a domain changes.

Why the split exists

Different audiences. The admin panel is used by a handful of organisers; the event sites are read by everyone. They have almost nothing in common in traffic shape, caching or authentication.

Different risk. The admin panel holds participant data and payment configuration and is deliberately noindex. The event sites are public and want to be indexed.

Different deploy rhythm. An admin change ships when it is ready. A change to the WL side touches every live event at once, so it moves more carefully.

Which one to change

Task	Repository
A settings screen, a chart, an export	tga-v3-admin-web
An endpoint the admin panel calls	tga-v3-admin-api
Anything a participant sees on an event site	tga-v3-wl-web
An endpoint the event sites call	tga-v3-wl-api
A column, an index, a migration	Both APIs read it — see Database schema

A schema change is the one that reaches everything. The two Laravel apps have separate migration histories against the same database, so decide deliberately which owns a change.

Versions and branches

A "version" is a branch of the WL pair plus its own running instance — not a fork:

Repository	v3	v4
tga-v3-wl-web	main	v4
tga-v3-wl-api	main	v4

v4 adds category-based paid registration. The admin side stays on main and serves both — it is version-aware rather than versioned.

Which version serves a given domain is stored per domain, on event_domains.version_key. See Domain resolution and the multi-version hosting brief.

v3 and v4 share the database

They are branches against one schema, not isolated environments. A migration run on the v4 branch affects live v3 events.

Local layout

All four are checked out side by side under /var/www/togoactive-development/:

admin-backend/                          tga-v3-admin-api
admin-frontend/                         tga-v3-admin-web
docs/                                   tga-v3-docs  (this site)
wl-event/
  frontend-wl-development/              tga-v3-wl-web      @ main
  frontend-api-wl-development/          tga-v3-wl-api      @ main
  frontend-wl-v4-development/           tga-v3-wl-web      @ v4
  frontend-api-wl-v4-development/       tga-v3-wl-api      @ v4

The v4 directories are the same repositories checked out on the v4 branch.

Read next

• How the admin works — a request through the admin pair
• How the WL side works — a request through the public pair
• Domain resolution — how one deployment serves every event