Direct answers about what Turbo EA is, what it can model, how it is licensed, how it is deployed, and how to move to it from another tool. Every answer here reflects the product as it ships today.
Turbo EA is a self-hosted Enterprise Architecture Management platform with embedded business process management. It builds a digital twin of your IT landscape by cataloguing applications, business capabilities, technologies, data objects and the relationships between them on a fully admin-configurable metamodel. The platform runs as Docker containers alongside a PostgreSQL database, entirely inside your own infrastructure.
Turbo EA is built for enterprise architects, IT leaders and transformation teams who need a working architecture repository rather than a slide deck. It suits mid-size organisations and growing IT departments that cannot justify a six-figure commercial licence, and it equally suits large enterprises that require complete data sovereignty. Because there is no per-seat licensing, read-only stakeholders can be invited without a procurement conversation.
Turbo EA is published on GitHub under the Functional Source License 1.1 with MIT Future License (FSL-1.1-MIT). You may self-host it for any internal purpose, commercial or not, with no fees and no seat limits, and you may read, modify and fork the source. Each release converts automatically to the MIT licence two years after publication, and releases up to and including v1.66.x are already MIT. The one restriction is that you may not resell Turbo EA or offer it to third parties as a competing product or hosted service.
Turbo EA is built by Vincent Verdet, an enterprise architect with more than 18 years of experience across global manufacturing, pharmaceutical and engineering organisations. He established the group-wide enterprise architecture function at Sulzer, a CHF 3.6 billion industrial engineering group, and he holds TOGAF Practitioner, SAP Enterprise Architect and SAP LeanIX certifications. The reasoning behind the product is set out in Why I built Turbo EA.
Yes. Turbo EA includes a Statement of Architecture Work editor with rich-text sections, version history, sign-off requests and DOCX export, architecture decision records with an audit trail, an EA risk register aligned to Phase G, and an admin-curated set of architecture principles that both documents reference. Business architecture and implementation governance therefore live in one repository. The metamodel is configurable, so it can equally be adapted to another framework or to one of your own.
Everything in Turbo EA is a Card, and cards are organised across four architecture layers: Strategy and Transformation, Business Architecture, Application and Data, and Technical Architecture. The default metamodel ships with 13 card types, including Objective, Initiative, Business Capability, Application, Interface, Data Object, IT Component, Tech Category and Provider, connected by 45 relation types. Administrators can add their own card types, subtypes, fields and relation types from the admin interface, because the metamodel is stored as data rather than code.
Turbo EA includes more than ten interactive report types. These are the portfolio bubble chart, the capability heatmap, the lifecycle roadmap, the dependency graph, the cost treemap, the matrix cross-reference, the data quality dashboard, the end-of-life risk report and the process map. Report configurations can be saved, shared with named users and exposed as OData feeds, and any report can be replayed as it appeared at a past date using the time-travel slider.
Yes. Turbo EA has a native BPMN 2.0 editor with draft, published and archived states, approval workflows and stakeholder sign-offs. Process elements link directly to EA cards such as applications and IT components, so you can see which systems support which process steps. Process maturity assessments covering efficiency, effectiveness, compliance and automation can be recorded against a process and tracked over time.
Yes. Turbo EA includes a portfolio Gantt with cost aggregation and health indicators, a hierarchical work breakdown structure with auto-computed completion, a Kanban task board, budget and cost tracking that syncs back to the initiative card, and a risk register with probability-impact scoring. Initiatives link to the capabilities and applications they change, so delivery work and architecture stay in the same repository rather than in two disconnected tools.
Turbo EA embeds AI in three places. Card description suggestions combine a web search step with an LLM extraction step and return a confidence score, editable text and source links. TurboLens performs vendor analysis and resolution, duplicate detection, modernisation assessment, guided target-architecture design and compliance scanning against frameworks including the EU AI Act, GDPR, NIS2, DORA, SOC 2 and ISO 27001. The built-in Model Context Protocol server lets AI clients both query the repository and write to it, under each user’s own role-based permissions. All of this works with self-hosted Ollama or with OpenAI, Google Gemini, Azure OpenAI, OpenRouter or Anthropic Claude.
Yes. The GitHub repository includes a one-click GitHub Codespaces launch that builds a fully loaded instance in your browser, with no local installation and no account beyond a free GitHub account. It comes pre-populated with a sample dataset of more than 150 cards across all architecture layers, along with business processes, strategic initiatives and their relations. The first build takes roughly five to ten minutes.
Turbo EA is deployed with Docker Compose. You fetch the compose file and the example environment file from the GitHub repository, set your database credentials and a JWT signing key, then run docker compose pull followed by docker compose up -d. The application becomes available on port 8920 by default, and the first account created automatically receives administrator rights.
The frontend is React 18 with TypeScript. The backend is FastAPI on Python 3.12. Data is stored in PostgreSQL, with the metamodel held as JSON so that card types, fields and relations can be changed without a code deployment. The bundled Docker stack uses non-root images for every service, and the codebase is continuously scanned with CodeQL while dependencies are monitored with Dependabot. Every security layer, from code review to signed releases and the weekly automated penetration test, is explained on the security page.
No. Turbo EA is self-hosted software that runs on your infrastructure and holds your architecture data in your own database. Neither the application nor any installed extension sends your usage data or your architecture data back to Turbo EA. The platform is air-gap capable and needs no outbound call to operate, which is set out in full in the privacy policy.
Turbo EA supports an unlimited number of users at no cost, because there is no per-seat licensing. Access is governed by admin-configurable roles with more than 50 granular permissions covering both application-level and card-level actions. Single sign-on is supported for Microsoft Entra ID, Google Workspace, Okta and any generic OIDC provider. Curated read-only views can also be published as public web portals that require no login at all.
No. Article 3(1) of Regulation (EU) 2024/1689 defines an AI system as a machine-based system that, for explicit or implicit objectives, “infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions”. Inference is the operative word, and the Turbo EA platform does not infer. It stores what people enter, evaluates calculation formulas that an administrator writes by hand in a sandboxed expression engine, scores data completeness against weights an administrator sets, and produces reports by aggregating rows in a database. Every output is a deterministic function of recorded input and explicitly configured rules.
The platform ships no model and no weights, it is trained on nothing, and it does not adapt its behaviour after deployment. The European Commission’s guidelines on the definition of an AI system place rules-based systems, basic data processing and hand-written mathematical optimisation outside the definition, and the Turbo EA repository sits squarely in that category.
That answers the platform. Turbo EA also ships optional features that call a large language model, and those are a genuinely separate question, set out in where Turbo EA calls a model. This assessment was last reviewed on 7 September 2026.
Nothing in Turbo EA calls a model until an administrator opens the AI settings and enters a provider endpoint and a model name. On a fresh install that configuration is empty and every feature below is inactive. The two permissions that can start a model job across a whole landscape are granted to the administrator role only by default.
Eight features can reach a model. Card description suggestions run a DuckDuckGo search for the card name plus a word derived from its type, send the resulting snippets to the model, and return a description, a confidence score and the source links. Portfolio insights send aggregated counts and distributions from the portfolio report together with your architecture principles, and return a short set of written observations. TurboLens vendor categorisation and vendor resolution send provider names with the names and descriptions of the applications linked to them. TurboLens duplicate detection and modernisation assessment send the name, description, vendor and lifecycle of the applications in scope. The compliance scanner sends a landscape summary and a sample of cards, and asks the model to assess them against the text of each enabled regulation.
The architecture assistant sends the most. To reason about a target architecture it includes the identifier and name of every active application, data object, interface, IT component, business capability and provider in the repository, with no upper limit, alongside your metamodel definitions and the requirement you typed. It is the one feature that puts a full inventory listing in front of the model, which is worth knowing before you point it at a commercial provider rather than at a model inside your own network.
Two things that look as though they should call a model do not. The built-in Model Context Protocol server exposes tools to an AI client that you bring and connect, so the model in that arrangement is yours and Turbo EA never calls it. The extension SDK exposes no model bridge at all, which means an installed extension has no sanctioned route to your configured provider or to its stored key.
Output is advisory almost everywhere. A description suggestion is editable text that reaches a card only when a user clicks Apply, portfolio insights are read-only, and the TurboLens analyses are written to their own tables for a person to triage rather than onto cards. Two exceptions deserve stating plainly. Compliance findings are saved as new, unreviewed rows when a scan finishes, although they never modify a card and a re-scan never overwrites a finding somebody has already worked on. And when you commit an architecture assessment, Turbo EA generates a description for each new card as it creates it, with no separate review step, for the cards and relations you ticked when you committed it.
Turbo EA supplies software that is capable of calling a model. It operates no inference service of its own, and nothing is routed through the supplier at any point. The model is always yours: either an Ollama instance running inside your own network, or your own account with OpenAI, Anthropic, Google Gemini, Azure OpenAI or OpenRouter. The obligations that attach to a general-purpose model sit with whoever made that model and placed it on the market.
When you switch these features on, you are the deployer of the model you chose. That is what brings the Article 4 duty to ensure a sufficient level of AI literacy among the people who use it, and, where you show generated output to other people, the Article 50 transparency duties, into your scope rather than the supplier’s. Turbo EA supports that by presenting AI output in its own panels and tables rather than mixing it into recorded data, and by keeping every suggestion editable before it is applied.
No customer data is used to train or fine-tune any model. Provider API keys are encrypted at rest, masked when the settings are read back, and stripped from workspace export bundles, so a copied workspace never carries a credential to another instance.
No. Nothing in the product does anything Article 5 prohibits, and none of the uses appear in Annex III. The features describe an IT landscape, propose text for a description field and flag applications that look like duplicates of one another. They make no decision about any person. They are not used in employment, credit, education, essential public or private services, law enforcement, migration or biometrics, and Turbo EA is not a safety component of a product regulated under Annex I.
If you integrate Turbo EA into a system that is itself high-risk, the analysis changes and it becomes yours, because you are the provider of that system and the Article 25 obligations along the value chain follow from that. Please get in touch through the consulting page before you build it, so that the information, technical access and assistance you need from the supplier can be agreed in writing rather than argued about after the fact.
Yes. Turbo EA ships a dedicated LeanIX importer with field mapping and a staged review, so you see exactly what will be created before anything is written. Importers for Ardoq, MEGA and Bizzdesign are on the roadmap and are not available yet. Any tool that exports to Excel or CSV can be loaded today through the bulk importer, which supports field mapping and a preview, so a migration can be rehearsed as many times as it takes.
Turbo EA ships a documented REST API, OData feeds that push saved views and reports into Excel or Power BI, and a bidirectional ServiceNow CMDB sync with field mapping, staged review and encrypted credentials. It matches IT components against endoflife.date for lifecycle tracking, embeds a self-hosted DrawIO editor with card-aware shapes, and connects to SMTP for notifications, surveys and sign-off requests. The Model Context Protocol server exposes the repository to AI clients such as Claude, Copilot and Cursor.
Capabilities outside the core are normally delivered as extensions. An extension is a signed bundle that installs from the admin interface and keeps working across core upgrades, so nothing has to be forked or patched. Extensions can add card types and reference data, new integrations, or entirely new pages, card tabs, admin panels and reports. Ready-made extensions are available in the Turbo EA Store, and bespoke extensions can be commissioned.
Yes. The author offers implementation and onboarding, bespoke extension development, sponsored core development, EA advisory and training workshops. For organizations that prefer a SaaS platform with vendor support, he also implements SAP LeanIX and sets up its governance, as an independent consultant rather than a reseller: he does not sell LeanIX licenses and the engagement starts once the subscription is signed. Sponsored core development funds a specific improvement that genuinely belongs in the core, which then ships to every user as part of the product. Note that this is a consulting relationship rather than a vendor support contract: there is no service level agreement on the free core. Scope and contact details are on the consulting page.
Run the browser demo before you install anything, or see how Turbo EA compares with the commercial platforms.