Internal Platform
LuxOS
One secure front door for every internal tool, and a standard way to create the next one, so no team rebuilds the same foundations again.
- 13 internal apps behind one login
- Access follows the org chart, set once in HR
- New app provisioned end to end
- Full audit trail kept for compliance
Once a company builds its third internal tool, it has built login three times, access control three times, hosting three times and an offboarding gap three times. Each one is a small decision. Together they are an operational liability nobody owns.
LuxOS is the answer to that: one secure front door for every internal application, access that follows the org chart automatically, and a standard, repeatable way to create the next tool. It is deliberately boring infrastructure, and it is the reason internal tools at PERGOLUX stopped being a risk.
How a new internal app gets stood up
- Request
- Checks
- Approval
- Auto set-up (repo · hosting · storage · access)
- Ship the app
- Security checks
- Deploy
- Live behind the gateway
Identity and access
- Staff sign in with their normal work account. External guests get a one-time email code that works for one application only and expires on its own.
- Who can see what comes from HR data rather than being maintained by hand. When someone changes role or leaves, their access follows automatically. Access lists maintained by hand are the single most common way internal permissions quietly rot.
- Admin rights can be granted for one application, for a limited time, and withdrawn at any point.
- There is one clear view of who has access to what, and a simple route to request more.
One front door
- Every application sits behind one address. No application runs its own login screen, and none of them expose where they are actually hosted.
- When you open an application it receives a signed, short-lived proof of who you are, so it can trust you without implementing authentication itself.
- External services that need to send data in have their own separate lane, so integrating one never opens a way around everything else.
- Hosted in the EU, with audit logging written off to the side so it never slows anything down for the person using it.
Standing up a new application
- It starts with a short form. The system helps pick the right storage and checks whether something similar already exists, so two teams do not quietly build the same tool.
- Once approved, everything is created and wired up automatically: the repository from the template, the hosting, the database, the configuration and team access.
- Credentials and keys are put in place at creation and kept encrypted, so nobody emails them to anybody.
- If a step fails it resumes from where it stopped, and a new application can be safely torn down right up until it goes live.
Keeping it in order
- One register of every internal application: who owns it, what it is for, whether it is live, and where the documentation is.
- Every application declares up front whether it handles personal data, and there is a tamper-evident record of what happened, kept for compliance.
- Offboarding removes access automatically. Guest access expires on its own. Health checks run in the background.
- There is a defined routine for rotating credentials and keys, and a grading for how sensitive each application and its data are.
The standard other teams build on
- A starter template, a toolkit that handles the fiddly parts (access rules, deployment, checklists, a go-live guide), and a playbook every team follows.
- The playbook is written as a seven-step journey, so a new team gets from idea to live application without having to reverse-engineer the platform.
- Nothing ships from someone's laptop. Every change goes through review and an automated round of checks before it deploys.
- Those checks look for known vulnerabilities, leaked credentials, out-of-date dependencies and risky configuration, plus a check that stops placeholder demo data reaching real users. When something is flagged, the person gets a ready-made prompt they can act on, and the checks cannot be quietly switched off.
Delivery and ownership
- I designed the platform and the standard around it, and delivered it through AI-assisted development.
- The decisions that matter here were operational, not technical: access should come from HR data because manual access lists always rot; guest access should expire because nobody remembers to revoke it; the register exists because 'who owns this tool' is the question that gets asked after something breaks.
- I own it in production, along with the playbook other teams follow.
The point
LuxOS is not an impressive piece of software. It is an impressive piece of operations: the difference between a company that has thirteen internal tools and a company that has an internal platform.