Software that doesn't break.

The agency built mostly WordPress and Laravel solutions for its clients, and relied on a large, steady pool of freelancers. Keeping the code somewhere wasn't enough. It needed what GitHub offers, joined up with three things GitHub doesn't: hosting development versions of the apps, showing progress to the client, and settling up with freelancers. No ready-made tool tied all of that together, so we built one.

The system created SFTP, Git and SSH accounts itself, so nobody had to go from server to server doing it by hand. The same route worked in reverse: the end of a contract meant revoking access in one place. A new person was at work after 15 minutes.

It all ran on Linux. We wrote the panel in PHP, but it never touched the server directly: system commands were carried out by a separate program in Go. Each freelancer had their own system account, created with useradd. Over SFTP, they saw their own projects and nothing else.

An ordinary server account says nothing about who may touch which repository, so we wrote our own authorization gate for Git over SSH. A forced command in sshd read SSH_ORIGINAL_COMMAND: git-upload-pack means read, git-receive-pack means write, and the gate checked the user's rights to that repository before letting the operation through. A freelancer could read one repository, push to another and have no way into the rest.

Connecting over SSH, a freelancer didn't land on the host but in the project's container. The account gave no shell on the server: ForceCommand took over every session and passed it to a small Go program, run through sudo with a single allowed command. Membership of the docker group is effectively root, and nobody from outside should get that.

The project was chosen by name: ssh -t [email protected] acme-shop. The program checked in the database whether this person had access to this project, then ran docker exec -it in its container with the user's UID, so files changed over SSH and SFTP had the same owner.

Accounts belonged to people, and environments to projects. Each project ran in its own Docker container with its own MySQL or PostgreSQL database, or several if it needed them. The databases were for development only, so the data of the agency's clients never reached freelancers. A mistake stayed inside its project: it didn't break anyone else's work or reach anyone else's data.

With hundreds of environments on shared infrastructure, one runaway process couldn't be allowed to stop the rest. So every container had CPU and memory limits, set with --cpus and --memory in Docker, which means cgroups in the Linux kernel.

A client or account manager could look at the work without access to anything else. The system created a subdomain in Nginx that sent traffic to the project's Docker container.

The agency ran all of this from its own panel. It could see who was working on what, and it granted permissions through roles and groups rather than person by person. That's also where it settled up with freelancers. An access log showed who had access to what, and when. Environments and databases were backed up twice a week.

The system held social security numbers, certificates, driving licences, home addresses, bank accounts and invoices. It showed what each user earned, and with enough of those numbers you could work out what the company itself earned. Very few people needed that data, but almost everyone could open it.

More than a hundred accounts: employees from engineering, product, design, analytics, sales, marketing, operations and support, plus outside companies handling support and operations as if they were staff. A couple of broad roles covered all of them, and between them they gave read and write access to almost everything. In practice, there was no access control worth the name.

Roles drawn up in a meeting room end up either too loose or in everyone's way. We started by mapping how the company actually worked: which departments, which kinds of employee, which tasks they did in the system, and what data each task really needed. Around thirty roles came out of that map.

The goal had two halves, and both mattered. Nobody should lose the ability to do their job. Everybody should lose access they didn't need for it.

Opening a module is one decision. What you see once you're inside is another. Each role carries its own level of access to sensitive data, so two people on the same screen can see very different amounts of it, each exactly what their work calls for.

Support can see what it needs to help a user, while product and engineering, who work on the same screens, don't see the sensitive fields at all. Some people lost access entirely, because their work never needed it.

Not every case fits a role. When someone needed more, they got a grant for that one person, either permanent or for a set time, and only after their supervisor and the security team had both approved it. Every grant was recorded in an audit log, so the answer to "who can see this, and why" is a lookup, not an investigation.

We rolled it out in stages, tested each one, then switched the company over. Where we weren't sure someone needed a permission, we left it out and waited for them to ask. Asking takes a minute and an approval. Undoing a leak doesn't work at all.

The permission checks were the easy part.

Deciding what counts as sensitive, and how sensitive, was the company's call. We worked alongside its security and data governance teams to map the data in the system: they classified it, and we built that classification into the access levels. The rest was agreeing with every department what it needed, getting supervisors behind the approval process, and fitting the model to how this company worked rather than to a textbook. We designed it, rolled it out end to end and handed it over for maintenance.