<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>LaraDep - Our Blog</title>
        <link>https://www.laradep.com/en/blog</link>
        <description>Read the latest news and updates</description>
        <language>en</language>
        <lastBuildDate>Wed, 20 May 2026 23:12:28 +0000</lastBuildDate>
        <atom:link href="https://www.laradep.com/en/feed.xml" rel="self" type="application/rss+xml"/>

                    <item>
                <title><![CDATA[How workspace isolation in LaraDep changed how I manage multiple clients]]></title>
                <link>https://www.laradep.com/en/blog/workspace-isolation-multiple-clients</link>
                <guid isPermaLink="true">https://www.laradep.com/en/blog/workspace-isolation-multiple-clients</guid>
                <pubDate>Wed, 04 Mar 2026 09:30:00 +0000</pubDate>

                                    <description><![CDATA[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.]]></description>
                
                                    <content:encoded><![CDATA[The state before workspace isolationBefore 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 practiceIn 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 operationsFor 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 enoughWorkspace 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.]]></content:encoded>
                
                                    <category><![CDATA[Security]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[MCP + Ansible: what surprised me and what actually works]]></title>
                <link>https://www.laradep.com/en/blog/mcp-ansible-what-surprised-me-and-what-works</link>
                <guid isPermaLink="true">https://www.laradep.com/en/blog/mcp-ansible-what-surprised-me-and-what-works</guid>
                <pubDate>Wed, 11 Feb 2026 10:00:00 +0000</pubDate>

                                    <description><![CDATA[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.]]></description>
                
                                    <content:encoded><![CDATA[How MCP came to LaraDepI noticed Model Context Protocol when Anthropic released the specification. First reaction: interesting protocol, but for Ansible operations it will be more of a toy than a tool. I tried it anyway — because the best way to test a hypothesis is to implement it and see what happens.The result surprised me. Not because it was revolutionary, but because of where it actually saves time and where it remains a nice demo without real operational impact.What MCP exposes in LaraDepThe MCP server in LaraDep exposes data via standardized tools. An AI assistant can query:A list of recent runs with outcomes and timestamps.Details of a specific run by UUID — inputs, outputs, preflight status.A run log stream for error analysis.Server and group lists with their metadata.Information about which passwords and tokens exist in the system and when they were last changed.What MCP never returns: the values of passwords and tokens. This is not a configurable setting — it is a hard-coded property of the system.Where MCP actually saves timeThe most valuable use case is post-incident troubleshooting. Instead of going to the admin panel, finding the run, opening the log, scrolling to the error, and mentally reconstructing what happened, I just ask: "Go through the run log for [UUID], find the first error, and summarize the context." The answer arrives in seconds. That saves 5-10 minutes on every incident review.The second use case is a quick infrastructure state check: "What servers are in the web-production group and when did the last successful run happen?" Again — previously I would click through the admin interface; now it is one question.Where MCP will not helpMCP will not help if you need to make a change. It is a strictly read-only tool for reading state and data. You cannot trigger runs, change configuration, or delete records via MCP — intentionally so. The AI assistant is an analytical tool, not an operator.It also will not help if your operational problem is in the playbook itself or in template logic. For that you need operational knowledge and code review, not an AI over metadata.My recommendationIf you manage Ansible operations and use Claude, Cursor, or Windsurf, it is worth trying MCP. It is not a game-changer, but it is a solid complement to an existing workflow. Especially for incident response and quick status queries, the return is clear.Next step: Use the documentation and comparison pages for full context.]]></content:encoded>
                
                                    <category><![CDATA[MCP / AI]]></category>
                                    <category><![CDATA[Automation]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[Why preflight is not just a status light: stopping a run before it does damage]]></title>
                <link>https://www.laradep.com/en/blog/why-preflight-is-not-just-a-status-light</link>
                <guid isPermaLink="true">https://www.laradep.com/en/blog/why-preflight-is-not-just-a-status-light</guid>
                <pubDate>Wed, 21 Jan 2026 09:00:00 +0000</pubDate>

                                    <description><![CDATA[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.]]></description>
                
                                    <content:encoded><![CDATA[When I realized I was doing preflight wrongFor a long time I thought preflight meant "check if the server is reachable and Ansible is installed". Technically that works, but practically it is not enough. A run you trigger on the wrong server or with an invalid variable will pass that kind of preflight and then cause exactly the damage you were trying to avoid.The turning point was a specific incident: a staging run with DB_HOST accidentally set to a production value copied from another workspace. Preflight said nothing because the server was accessible. The run completed. The production database received inconsistent data.What real preflight must coverAfter that incident I rewrote what preflight means in LaraDep. Technical availability is not enough — you need to verify the context of the run. Four things have saved me more stress than I expected since then:Target correctness: Is this genuinely the server or group you intend to change? No accidental staging/production swap.Input completeness: Are all required variables filled with meaningful values?Configuration consistency: Are the dependencies the template relies on in their expected state?Permission check: Does the logged-in user have the right to execute this change in this workspace?What it looks like in practicePreflight in LaraDep is a gate, not a status light. If any condition is wrong, the run does not start and you get a concrete description of what is missing. It is not a polite warning — it is a hard stop. And yes, at first it annoyed me a little. Then I remembered that incident and came to appreciate it.For teams where multiple people trigger changes, this matters especially. A senior operator does a mental preflight on their own. A junior or new colleague does not — and the gate is what protects you from their honest mistakes.What preflight will not solvePreflight does not catch logical errors inside the playbook itself. If your template does the wrong thing correctly, preflight will not tell you. That is why good template composition and workflow discipline need to exist alongside preflight, not instead of it. Each layer solves a different problem.Next step: Use the documentation and comparison pages for full context.]]></content:encoded>
                
                
                
                            </item>
            </channel>
</rss>
