Cookie settings

We use cookies

Necessary cookies keep the website working and store your choice. With your consent, we can also use functional cookies to remember the theme preference and analytics cookies to measure website usage.

You can accept optional cookies all at once, reject them, or choose individual categories. You can change your consent later; details are available in the Cookies Policy.

Back to blog

March 4, 2026 · 2 min read

How workspace isolation in LaraDep changed how I manage multiple clients

Managing multiple clients in one Ansible setup without clear separation is like carrying all keys on one ring with no labels. Here is how the workspace model solves this.

The state before workspace isolation

Before I built the workspace model into LaraDep, a multi-client setup looked like this: one Git repository, one Ansible vault for all secrets, folders named after clients, and an unwritten team agreement of "do not touch what is not yours". Does it work? Technically yes. Safely? Absolutely not.

Mixing environments in that kind of setup is a matter of inattention, not bad intent. You switch to the wrong folder in the terminal, run against production instead of staging, and the outcome tells you what happened. If you are lucky, it is only lost time. If not, it is an incident.

What workspace isolation means in practice

In LaraDep, a workspace is a data context that physically separates:

  • Servers and their groups from other workspaces.
  • Ansible variables and the secret store from other workspaces.
  • Run history and audit records by workspace context.
  • Permissions — who can do what within a given workspace.

Switching a workspace does not just mean a different browser tab. It means you cannot accidentally view or run anything in the wrong context because the system will not allow it. It is not "we hope you notice". It is a structural constraint.

A concrete case: agency operations

For agencies, the workspace model is probably the biggest added value of LaraDep. Each client gets their own workspace. Onboarding a new project means creating a workspace, adding servers, configuring variables, and assigning permissions. It is an explicit act — not "give Jan access to the folder".

Run audits work by workspace context. When a client asks "what did you do with us last month", the answer is a few clicks away, not an hour of digging through Git history.

Where the workspace model is not enough

Workspace isolation is a governance layer, not a substitute for good template composition or runbook discipline. If your playbook does the wrong thing, the workspace will not catch it. Each protection layer solves a different problem, and the workspace model solves exactly and only: context and access isolation.

For a complete operational model, you need workspace isolation together with preflight, templates, and audit history. Each layer helps less alone than all of them together.

Next step: Use the documentation and comparison pages for full context.

You might also like

02/11/2026 · 1 min read

MCP + Ansible: what surprised me and what actually works

I added MCP to LaraDep with low expectations. Fast queries over logs and metadata turned out more useful than expected. Here is an honest review.

Show

01/21/2026 · 1 min read

Why preflight is not just a status light: stopping a run before it does damage

I originally treated preflight as a formality. Then came a run that passed without errors and still caused problems because we were not asking the right questions.

Show

Subscribe to our Newsletter

Stay updated with our latest news and articles by subscribing to our newsletter.

Esc Close