Skip to content
Article SepoDesk
☀️ Light Clean and bright
📜 Sepia Warm and vintage
🌤️ Light Gray Subtle and neutral
🔵 Light Blue Calm and serene
🌙 Dark Easy on the eyes
🌑 Dark Gray Deep and modern
🔷 Dark Blue Professional and sleek
🌿 Forest Calm and natural

SepoDesk is a full-stack framework built on PHP, with plain JavaScript, HTML and CSS on the front. It has no external dependencies — no Composer tree, no npm tree, no build toolchain beyond a PHP script that ships with the project. What you deploy is exactly what you read.

It renders in two modes, and the mode is a deliberate choice per surface:

  • Server-rendered. Documentation, auth screens and the mobile dashboard are produced on the server. They work with JavaScript off, arrive as finished HTML, and cost one request.
  • Client-rendered. The desktop shell loads once from the server, then hands the UI to the browser. From that point apps mount, unmount and redraw without another page load.

Where things are stored

SepoDesk splits storage deliberately, and knowing which half you are in explains most of the rest of this handbook.

Content is files. Pages, blog posts, products, courses, forms and polls live on disk as Markdown with front matter. So do their records — orders, bookings, enrollments, quiz results and membership ledgers are JSON under Content/. You can read them, diff them, grep them, back them up with cp, and version them in Git. Content changes review in the same pull request as the code they touch, and there are no content migrations because there is no content schema to migrate.

Identity and application data are SQL. SepoDesk runs on four databases: users and API keys, the UI and project registry, the data manager, and installed app storage. MySQL/MariaDB and SQLite are both first-class. Table structure is versioned as files under Migration/Versions/, so schema changes review like code even though the data does not.

That split is the design: the things you author belong in your editor and your repository; the things your users generate belong in a database that can index, join and enforce constraints. Neither half pretends to be the other.

Why SepoDesk

Zero dependencies, zero lock-in. No package manager, no build step, no vendored framework you don't control. The entire stack is code you can read in an afternoon, which means fewer moving parts to break, patch, or audit — and nothing that can go stale in a lockfile.

Runs where PHP runs. Shared hosting, a local XAMPP stack, or mounted inside WordPress as a plugin. No container, no queue worker, no build server, no services beyond PHP and a database. If a box can serve WordPress, it can serve SepoDesk.

Reach every visitor. Because the important surfaces are server-rendered, they load fast, index cleanly, and work on slow connections and locked-down browsers with scripting disabled. Rich interactivity is layered on top for those who can use it — never required to see the content.

Batteries included. Around twenty apps ship in the box for system administration, data tools and the query builder. On the content side, complete product surfaces are built the file-based way — documentation with search, a blog with threaded comments, changelogs and signed releases, a storefront with carts and orders, multi-tenant stores, a booking calendar with availability and per-day planning, and a full learning platform with courses, enrollment and teacher profiles.

Your data stays yours. Orders, bookings, enrollments and student records are files on your own disk; users and app data are in databases you administer. No third-party SaaS sits between you and your users. CSRF protection, role-scoped navigation, encrypted stored credentials and server-side admin gates are built in, and sensitive stores are sealed against direct web access.

Improves in place. The system updates itself from a signed package, so a live install moves forward safely without a redeploy. Apps install into a running system instead of being compiled into it, and grids, pages and workflows extend through hooks and plugins rather than forks.

Serve. Master. Improve.

The motto is the operating philosophy, not a slogan:

  • Serve — deliver to everyone, reliably. Finished HTML in one request, no-JS fallbacks, and hosting requirements modest enough to run almost anywhere.
  • Master — own the whole stack. No dependencies, no lock-in, and content you can open in a text editor. Nothing about your system is hidden from you.
  • Improve — evolve without fear. Safe in-place updates, installable apps, and extension points that let the system grow while staying yours.

The desktop model

Every app is a window. Windows are movable, stackable, and there is no cap on how many you open at once — the shell keeps each app's state alive while its window exists. Apps are installed into a running system rather than compiled into it, and the system updates itself in place from a signed package.

Documentation lives on disk

Every page you are reading is a file under Content/Pages/. Add one and it appears in the sidebar; rename it and the URL follows. No database is involved in serving this page.

That makes docs reviewable in the same pull request as the code they describe. See Writing documentation for the format.

What installing actually involves

Getting SepoDesk running is a handful of deliberate steps, not a one-liner. On a local machine: create the databases, write .env, generate a secret key, run the installer, build the front-end bundles. In production there is more — the databases and their users are created in your host's control panel first, credentials are encrypted before they go anywhere near a config file, and the installer is opened and then closed again behind a lock.

None of it is hard, and all of it is written down. Follow Getting started in order rather than improvising; the steps depend on each other, and two of them are awkward to undo.

Where to go next

If you want to…Read
Get a local instance runningGetting started
Deploy to a live hostGetting started
Understand the request and render pathArchitecture
Write or edit a documentation pageWriting documentation
Build, install or package an appApps and windows
Write an app's server-side classBuilding an app backend
Look up what a shared trait doesTrait reference
Build an app's UI, windows and templatesBuilding an app front end
Look up a DomBuilder methodDomBuilder reference
Extend a grid with hooks or pluginsData UI, hooks and plugins
Ship an update to a live installSystem updates

Supported by