DEV Community: Peter Wurbs

Beyond Jira: Reclaiming Agile Sovereignty with Open Source

Peter Wurbs — Mon, 13 Apr 2026 11:10:01 +0000

A pragmatic review of self-hosted alternatives for modern teams and why I’ve started building a leaner solution for our own needs.

Motivation

For me, Jira was the gateway to Agile methodology and the Kanban principle. Since discovering it, I haven’t wanted to miss the methodology for a single day. I use Kanban in my professional life, but also privately, and even within my family.

Unfortunately, years ago, Atlassian discontinued our server licenses. Now, they are forcing us into the cloud — whether we like it or not. Aside from that, Jira has always been too expensive. My team actually only used about 30% of the features; in exchange, the software has developed into a “Moloch” over the years: vulnerable, complex to configure, plagued by frequent security updates, and burdened by long startup times.

Because we don’t want to lose the methodology, but we absolutely have to move away from Jira, I set out on a journey.

In Europe, everyone talks about IT Sovereignty. An “Exit Jira/Atlassian” strategy would be sovereignty in action. But which company actually follows through?

Since I no longer had access to Jira myself but refused to give up the Agile way of working, I spent some months attentively collecting information and testing tools. This article is the result of that journey.

The Criteria for a Well-Founded Analysis

To do this properly, we need a checklist. At the very top stands Open Source. As a lesson learned from the Atlassian disaster (Vendor Lock-in) and the resulting loss of our own agency, any alternative must provide its software as Open Source on GitHub or similar platforms. Even if this is only guaranteed for a “Community Edition,” it ensures that in an emergency, we could take the source code and develop it further ourselves. This only counts, of course, if that edition includes the essential functions and a permissive license.

I am not trying to cover the functional scope of Jira 1:1. I am limiting myself to core functions and a pragmatic, sensible implementation. My target audience is Agile (DevOps) teams with lean regulations and a free way of working. I’d gladly trade a few barely used features for software that is slim, stable, and secure.

To keep this analysis focused, I have defined the following “KO Criteria” (Exclusions):

No Classic Project Management: I am leaving out traditional PM software. I want a tool for Agile methodology, not a replacement for Microsoft Project. ;)
No Legacy Bloat: This comparison is not for companies that need Jira for complex legacy processes, rigid quality gates, or endless checklists.
No Simple Task Lists: I am not looking at simple To-Do apps.
No Cloud-Only: True sovereignty requires Self-Hosting. If we can’t control the installation and the data, it doesn’t make the list. Even EU-hosted, GDPR-compliant clouds don’t protect us from a provider’s future forced migrations.

Finally, the tool should feel good. Nothing is worse than having to work daily with software you don’t enjoy using. Therefore, the UI plays a major role.

TL;DR: The Quick Summary

For those short on time, here is the summary of results, recommendations, and my personal conclusion. See “The Long Story” for a detailed presentation of the checklist and the technical results of the individual tool assessments.

The assessment was done along the following categories:

Self-Hosting / Open Source / License / Costs
Features
Architecture
Deployment
Security / Privacy

Tool Assessments by Recommendation Status

❌ ❌ Asana, Blossom, Backlog: Enterprise software trying to fully replace Jira. Closed source, requires registration, and can be very expensive.
❌ Open Project, Plane: Open Source, but uses an “Open-Core” model. Overloaded with features, but essential features are often missing in the community/free editions.
❌ Kanboard, WeKan, Kanba: 100% Open Source, but the tools are either no longer maintained or the UI feels significantly outdated. I would not like to work with it.
✅❓ Kan.bn, Kaneo, Vikunja: 100% Open Source with strong communities. Slim, attractive Kanban-focused applications. However, they lack core features familiar to Jira users and are positioned more as Trello substitutes. Limited recommendation.
✅❓ Planka: Features are comparable to the category above. Strong community and public source code, but the license (not Open Source) imposes restricted usage terms. Limited recommendation.

This is only my personal opinion. So, there is no “you must use this tool” statement. Instead, everyone must assess and decide for themselves, based on their specific team methods and priorities. So, use this information but decide for yourself… 😉

Conclusion: Why I started building my own tool?

But if I were asked which tool I would actually choose, I would say “none of them”. Unfortunately, no tool fulfilled all my requirements. If a tool looks good, it lacks features. If the features are there, the UI is clunky. If the function is okay, the license is not.

Even the tools with a partly recommended rating have these issues:

Missing Core Features: Release management (aka versions or milestones) is not there at all, not to mention the support for SCRUM. Backlog management is mostly not there or poorly implemented. Tools are rather positioned as a substitute for Trello and not for Jira.
Signs of accumulated technical debt and too many dependencies used. This unnecessarily increases the supply chain surface and results in an increased effort for maintenance and updates.
Security issues: Too many useless, redundant, deprecated, or not-maintained dependencies used, no HTTP security headers to protect clients against XSS, partly weak access/session token management.
No tool combines a classic Kanban board view with flexible daily planning to easily organize the workflow and time side-by-side.

I realized that the ‘perfect’ balance between the complexity of Jira and the simplicity of a basic board doesn’t really exist. That’s why I started my own project “wuflow” to see if I could bridge that gap.

It’s an attempt to marry a nice, modern UI with the ‘Sovereign’ requirements of a self-hosted agile engine, combined with a security-first approach. It is currently in its early stages — focused on being lean, secure, and open-source. It’s not a ‘Jira-killer’ for everyone, but it’s a step toward true IT sovereignty.

As a side note: I also wanted to see how far I could get with AI-assisted development anyway, building a new tool from scratch while keeping the supply chain surface as small as possible.

And I like to make good things, which simply work and provide added value. There is a deep satisfaction to have full control over concepts, code, features, implementation, prioritization…

If you share this vision, I’d love for you to check it out on GitHub, give it a star, deploy and test yourself, and raise issues for bugs or new features:

pwurbs / wuflow

wuFlow is a simple, modern, and lightweight issue tracking and planning application.

wuFlow

General

wuFlow is a simple, modern, and lightweight issue tracking and planning application. It is designed to combine the immediate visual overview of a classic Kanban board with structural planning capabilities to help you organize tasks effectively without unnecessary complexity This tool wants to help you to organize, balance and track the work in a team to achieve a better flow of work by a transparent visualization. This is one of the main intentions of a Kanban board. The usage is not limited to software development teams, it can be used by any person, group or even families that wants to organize and track their work.

We developed this app having the following goals in mind:

Create a modern and lightweight issue tracking solution focused on the mostly used core functions to ensure a good flow of work.
Can be used without expensive subscriptions or being forced into…

View on GitHub

The Long Story

Checklist Details

Self-Hosting / Open Source / License / Costs

Self-hosting: Must be possible and well-documented.
Availability: Source code must be public (e.g., on GitHub).
Licensing: A permissive Open Source license for unrestricted usage (AGPL is the absolute baseline).
Community Integrity: Any feature restrictions in a “Community Edition” must not violate the core feature requirements below. We are evaluating self-hosted versions, not Cloud SaaS offerings.
Maintenance: Active development, regular official releases (with notes), and a transparent security process.
Cost: The tool must be free, at least for individuals or small teams.

Features

Lean Agility: Focused on core features. No bloated “feature monsters” that are difficult to manage. Keep it simple, stupid!
UX/UI: A clean, modern interface with Drag-and-Drop functionality.
Kanban: Configurable columns to match the team’s flow.
Backlog Management: A dedicated area to prepare and refine issues before they move to the board.
Archiving: Ability to move issues to a read-only area for future reference.
Release Support: Management of versions or milestones for tracking specific deliveries.
Multi-Project: Separation of work into different project domains.
Granularity: Support for subtasks or checklists, labels, and prioritization per issue.
Discovery: Robust filter and search capabilities.
Content: Rich text descriptions (Markdown preferred), issue comments, and attachments.
Context: Support for issue dependencies and internal links.
Time Management: Deadlines for both issues and subtasks, plus a daily planning/calendar function.
User Management: Role-based access control (RBAC) and project assignment. Authentication via local user and optionally via OIDC.
Configuration: Straightforward in-app configuration.

Architecture

Modern Stack: Lightweight software with minimal legacy burden.
Pragmatic Frameworks: Avoidance of unnecessary “framework bloat.” We only want dependencies that provide real value, thereby maximizing independence and reducing maintenance overhead.
Supply Chain Security: Minimizing the dependency surface to reduce security risks.

Deployment

Configuration as Code: Simple, flexible system bootstrap configuration.
Containerization: Deployable via a publicly available, well-maintained container image.
Easy Evaluation: The ability to test the tool without complex external dependencies (e.g., internal SQLite support for dev/testing).
Speed: The tool must start and stop quickly.
Cloud Native: Kubernetes-ready with health check endpoints, Prometheus metrics, and Helm charts.
Persistence: Support for external databases (PostgreSQL preferred) and S3 storage for file uploads.

Security / Privacy

Identity: Secure authentication, session, and token management. Transfer in cookies.
Cookie Security: Tokens and session IDs must use secure attributes (httpOnly, Secure, SameSite, MaxAge).
Hardened Headers: Essential HTTP security headers must be set (especially a strong Content Security Policy) to protect the client.
Self-Containment: No external libraries or dependencies should be loaded at runtime; all code must be packaged into the binary.
Minimal Supply Chain Surface: Only essential, actively maintained dependencies.
Privacy-First: Zero tracking, zero telemetry, and no “calling home.”

My Assessment Methodology

In my experience, it doesn’t make sense to assign weights to these criteria and calculate a numeric score. Often, a metric will tell you a tool is “mathematically” 90% perfect, yet it still feels wrong or clunky in daily use. I prefer to view the tool as a holistic entity.

To save you from reading massive, unmanageable comparison tables, I have applied a “Fail-Fast” audit approach. I assess each tool category by category, starting with its Open Source status. The moment I encounter a “hard violation” of a core criterion, I stop the assessment. Because of this, e.g. you won’t find a deployment analysis for every tool — if it failed on licensing or core features.

To keep this guide concise, I will focus on the relevant negative findings; I will only highlight positive points if they are truly exceptional.

Let’s dive in…

Legend

❌ No recommendation or KO criteria reached.

⚠️ Some issues to be considered but no hard stop.

✅ Requirements met or (limited) recommendation.

The Tool List

Asana, Blossom, Backlog

I mention these tools only because they frequently appear at the top of “Best Jira Alternatives” search results. However, for a team seeking IT sovereignty, they are non-starters.

❌ Self-hosting / Open Source / License / Costs

Proprietary / Closed Source: No access to the underlying code.
Cloud-Only / Account-Locked: Requires third-party registration and hosting.
Restrictive Pricing: Free tiers are often limited to 1–2 users; professional use requires expensive monthly subscriptions.

❌ Summary

No Recommendation. These tools are simply a move from one “Black Box” (Atlassian) to another. They offer no path toward true independence or code-level control.

Open Project

Website: https://www.openproject.org

Github: https://github.com/opf/openproject

✅ Self-hosting / Open Source / License / Costs

Open-Core Model: While the base is GPL licensed, the “Enterprise Add-ons” are contained in the same repository but require a paid license key to unlock.

❌ Features

Paywalled Essentials: Paradoxically, for a tool often marketed for Agile, the Agile Boards (Kanban and Team-Boards) are missing from the Community Edition.
No Community SSO: Essential security features like OpenID Connect (OIDC) or SAML are also restricted to paid versions.
Complexity Overload: It attempts to be an all-in-one suite (Gantt charts, time tracking, cost modeling), leading to a cluttered and overcomplicated UI that violates the “Keep it Simple” principle.

❌ Architecture / Security

A high volume of critical security patches suggests systemic flaws in the process or architecture, demanding a relentless cycle of constant patching.

❌ Summary

No Recommendation. OpenProject is a legacy “feature monster.” It is bloated, difficult to manage, and hides the most crucial agile features behind a paywall. It fails the “IT Sovereignty” test because your team’s agency is still restricted by a vendor’s license key.

Plane

Website: https://plane.so/

Github: https://github.com/makeplane/plane

✅ Self-Hosting / Open Source / License / Costs

Open-Core Model: Uses the AGPL license, but the repository primarily contains only the free/community features.
Paywall Strategy: Essential features for scaling are intentionally kept out of the open-source version.

❌ Features

The “Power” Trap: While extremely powerful and feature-rich, it suffers from the same bloat we are trying to escape. It feels like it’s trying to do everything for everyone.
Restricted Essentials: Crucial features for professional agile teams are missing from the Free Edition:
User Cap: Limited to only 12 users in the free version.
No Release Management: Milestones and Cycles (their version of Sprints/Releases) are severely restricted or locked behind tiers.
No OIDC: Single Sign-On (SSO) is a paid enterprise feature.

❌ Architecture

Technical Debt & Complexity: The software has grown massive over the years. It is a large codebase with a high number of dependencies, making it a heavy lift to maintain and secure.

❌ Summary

No Recommendation. Plane is too big, too complex, and too restricted. Like OpenProject, the most valuable agile functions are only available in paid, closed-source editions. It is essentially “Jira in a prettier dress,” carrying over the same issues of feature bloat and vendor dependency. For a team seeking a lean, truly sovereign tool, Plane is simply “too much.”

Kanboard

Website: https://kanboard.org/

https://medium.com/blog/newsletter?source=promotion_paragraph---post_body_banner_beneficial_intelligence_nl--14556d709c65---------------------------------------

Github: https://github.com/kanboard/kanboard

❌ Self-Hosting / Open Source / License / Costs

Pure Open Source: 100% open source without “Community Edition” limitations.
MIT License: Very permissive.
Maintenance Warning: The Github repository is officially marked as being in Maintenance Mode.

❌ Features

Fragmented Functionality: Most advanced features require third-party plugins. However, there is no official approval process or code review for these plugins, creating a massive security and stability risk.
Missing Core Agile Features:
No Backlog Management: It only offers a single board column, lacking a true staging area for refinement.
No Archiving: Issues can only be “closed,” losing visibility and context.
No Release Management: Standard agile hierarchy and delivery tracking are absent.
OIDC only via plugin.
UX: The interface feels like a relic from the early 2000s — it looks pretty old-fashioned.

❌ Summary

No Recommendation. While it fulfills many checklist items regarding licensing, open source, and simplicity, it lacks required modern polish and active development. Relying on unvetted plugins to achieve basic functionality (like OIDC) contradicts the “Security-First” approach.

WeKan

Website: https://wekan.fi/

GitHub: https://github.com/wekan/wekan

✅ Self-Hosting / Open Source / License / Costs

100% Open Source: No “Premium” tiers or gated features.
MIT License: Very permissive.

❌ Features

Dated Interface: The UI feels cluttered and stuck in the past. It lacks the “snappiness” and clean aesthetics of modern web applications.

⚠️ Architecture / Deployment

MongoDB: WeKan relies on MongoDB. While technically functional, this is an “unusual” choice for a modern, lean tool. Furthermore, MongoDB’s SSPL license can create complex legal hurdles for certain production environments and enterprise compliance.

❌ Summary

No recommendation. Even though WeKan is widely used and respects the user’s freedom, it fails the “Feel Good” test. In a world of modern, high-performance web apps, its UI is a significant barrier to adoption. Additionally, the dependency on MongoDB adds unnecessary architectural and licensing weight.

Kanba

Website: https://www.kanba.co

GitHub: https://github.com/Kanba-co/kanba

⚠️ Self-Hosting / Open Source / License / Costs

Open Source Status: 100% open source under the MIT license.
Maintenance Concerns: The last release on GitHub was in August 2025. Is it maintained anymore?

❌ Features

Vague Capabilities: The documentation is remarkably thin. Both the website and GitHub offer only generic buzzwords like “Kanban boards” and “Team collaboration,” without detailing the actual depth of the features.
High Barrier to Entry: It is currently impossible to easily “test-drive” the self-hosted option without a significant manual setup effort.

⚠️ Deployment

Poor Developer Experience: Documentation for self-hosting is lacking. Most notably, there is no public container image available, forcing users to build from source.

❌ Security

Vulnerable Core: A quick audit reveals outdated dependencies containing Critical and High-severity security vulnerabilities (e.g. next, flatted, glob, and lodash).

❌ Summary

No Recommendation. I fail to see the logic in offering a self-hosted version without providing a ready-to-use container image. The combination of stagnant development, critical security vulnerabilities, poor documentation, and the lack of an easy evaluation path makes Kanba a risky choice.

kan.bn

Website: https://kan.bn/

Github: https://github.com/kanbn/kan

✅ Self-Hosting / Open Source / License / Costs

100% Open Source: No feature limitations or “paywalled” tiers for the self-hosted version.
License: AGPL.

⚠️ Features

The UI is sleek, responsive, and covering many items from the checklist. However, there are significant gaps for professional Agile teams:

Missing Core Logic: No native release management (versions) and no archive management.
Disconnected Backlog: While you can create a dedicated backlog board, it isn’t integrated with the active working boards.
Missing Productivity Tools: No full-text search, no issue dependencies/links, and no daily planning functionality.

⚠️ Architecture / Deployment

While the project is “fresh” and free of legacy code, its modern stack comes with a dependency bloat.
The choice of dependencies is questionable for a lean tool. It uses a heavy stack (Next.js, tRPC, Drizzle, Stripe SDK, Novu, i18n). In my opinion, some of these are unnecessary for a self-hosted engine and increase the maintenance burden and attack surface.

⚠️ Deployment

Self-hosting via container images is well-documented, but there are some issues:

Database Rigidness: The app requires an external Postgres container. I was unable to get it running with the internal PGlite database for easy testing.
Unusual Setup: It uses a migration script to initialize the database on the first run, which is non-standard.
Missing Orchestration: No Helm chart is available for Kubernetes deployments.
Release Status: GitHub only lists “prereleases,” which may decrease trust for teams requiring a stable production environment.

⚠️ Security / Privacy

The supply chain surface is a concern here. There are too many direct and transitive dependencies. This amongst others results in:
Trivy found 1 critical and 12 high-severity issues in the container image
Some used packages or not maintained anymore (react-beautiful-dnd, tiptap-markdown) or didn’t get any updates during the last 2 years.
Missing security headers: No X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, or Content-Security-Policy headers are configured.

✅❓ Summary

Limited Recommendation. This is a potential project with a nice UI. If your team is moving from Trello, this is a recommended “Sovereign” choice. However, if you are moving from Jira, the missing release/backlog features and the security “noise” from the dependency bloat are hard to ignore. It’s a great board, but not yet a complete “Agile engine.”

Kaneo

Website: https://kaneo.app/

Github: https://github.com/usekaneo/kaneo

✅ Self-Hosting / Open Source / License / Costs

True Open Source: MIT License with a clear “free forever” commitment.
Permissive MIT license.

⚠️ Features

Kaneo covers significantly more ground than kan.bn and feels more like a professional platform. However, the “Agile” depth is still shallow:

The Good: Strong integration ecosystem (GitHub, Gitea, Slack), S3 support for attachments, and a surprisingly functional Gantt view.
Agile Hierarchy: It includes a backlog and archive management, though the archive lacks a “Read-Only” mode to prevent accidental edits.
The Gaps: It lacks daily planning, subtasks, and release management(versions).
Flexibility: A major drawback for many teams is that Kanban columns are not yet configurable — you are stuck with the predefined workflow.
UI/UX: The interface is clean but follows a very “dark/gloomy” aesthetic that may not appeal to everyone.

⚠️ Architecture

Modern Stack: Built on a clean, modern foundation (Next.js, Postgres).
Too many overlapping frontend dependencies: For example, the project bundles multiple markdown renderers and a rich-text editor, which feels redundant and increases the bundle size.

✅ Deployment

Self-hosting via Container image well supported and documented.
Fast startup.
Helm chart available.
App only runs with external Postgres container.

⚠️ Security / Privacy

Supply Chain: With over 80 production dependencies, the attack surface is wide.
Maintenance Debt: Several “utility” libraries (like tippy.js) have fallen behind or are no longer actively maintained.
Missing security headers: No X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, or Content-Security-Policy headers are configured.

✅❓ Summary

Limited Recommendation. Kaneo is a strong evolution of the minimalist board concept. While similar, it provides a more complete feature set than kan.bn — specifically its backlog, archive management, and Gantt view — making it a viable candidate for general project management. However, for professional Agile teams, the lack of subtasks, release management, and configurable columns could be significant hurdles. If you can embrace the gloomy UI and are prepared to manage the security/dependency risks yourself, Kaneo is a recommended tool, especially given its credible “free forever” open-source promise.

Vikunja

Website: https://vikunja.io/

Github: https://github.com/go-vikunja/vikunja

✅ Self-Hosting / Open Source / License / Costs

True Open Source: AGPL license with a firm commitment: “Vikunja is and always will be Open-Source and freely available”.
No Paywalls: 100% open source without feature limitations for the self-hosted version.

⚠️ Features

Vikunja covers a large portion of our checklist and offers diverse working modes, but it is more “To-Do” oriented rather than purely Agile.

Rich Views: Provides List, Gantt, Table, and Kanban views out of the box.
Time Management: The “Upcoming” section offers better time visibility than its peers, though it only lists deadlines/start dates and lacks true day-to-day planning.
Missing Agile Core: No backlog management, no task archiving, no releases (versions), and no activity log.
Admin Limitations: Lacks a global admin dashboard to centrally manage all users, roles, and cross-project assignments (relies heavily on Team-level management).
UX Inconsistencies: While the main board UI is clean, the interface for editing individual tasks or projects feels clunky and poorly designed.

✅ Architecture / Deployment

Modern Stack: A fresh, well-designed application without historical legacy bloat.
Operations: Self-hosting via Container image well supported and documented, fast startup, and very easy to deploy for testing.
Observability: Native Prometheus metrics included out of the box.
Optimization: Some frontend dependencies could still be pruned to reduce supply chain risks.

⚠️ Security / Privacy

Hardening: Missing essential security headers (No Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options headers are set).
Token Storage: JWT access tokens are stored in localStorage, exposing them to potential XSS attacks (though the refresh token correctly uses HttpOnly cookies).
Patching Fatigue: A high frequency of security fixes is a double-edged sword. While it shows active maintenance, it can also be a symptom of architectural weaknesses or a flawed testing process.
Active Threats: At the time of writing, there is a critical security advisory that has been open on GitHub for over two weeks.

✅❓ Summary

Limited Recommendation. Vikunja is comparable to kan.bn and Kaneo but feels significantly more mature regarding deployment, operational options (like Prometheus metrics), and integrations. Unfortunately, it suffers from the exact same missing Agile features: no archiving, no backlog management, and no releases. Furthermore, the UI takes some getting used to. Because of the frequent security patches and active advisories, adopting Vikunja requires a highly disciplined, well-organized update management process. If you can handle the operational overhead and don’t strictly need Jira’s release hierarchy, it is a highly capable and recommendable tool.

Planka

Website: https://planka.app

Github: https://github.com/plankanban/planka

⚠️ Self-Hosting / Open Source / License / Costs

The “Open Source” Trap: Planka does not use an OSI-approved open-source license. It uses a custom “Community License” with significant restrictions on commercial and business use.
Business Use: While free for internal use within your own organization, any use beyond that requires a paid Pro edition or Cloud subscription.
Feature Gating: Several features (like the Calendar view and the “Card Inbox”) are locked behind the Pro version.

⚠️ Features

Visualization: UI is fine, but the visualization of the cards in the row („list“) of the Kanban board takes some getting used to. Colors are not configurable.
No backlog management like in Jira, only the “First Column” method, which is not sufficient.
No release management to track versions or milestones.

⚠️ Architecture

While a mature open-source project, it shows clear signs of accumulated technical debt. There is some weakness in security and dependency usage. E.g. the project relies on Sails.js — a framework that is increasingly considered a legacy burden in 2026.

✅ Deployment

Deployment via Docker is seamless, documentation is excellent, and it offers a well-maintained Helm chart for Kubernetes. Startup is remarkably fast.

⚠️ Security / Privacy

Hardcoded Secrets: The application uses hardcoded default secret keys and, alarmingly, does not check or force a change at startup.
No HTTP security headers: No X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, or Referrer-Policy
Frontend Risk: There is a high XSS risk due to the usage of dangerouslySetInnerHTML, compounded by the total lack of Content Security Policy (CSP) and other security headers (HSTS, X-Frame-Options).
Dependency Jungle: The project suffers from extreme “micro-package” bloat, partly unmaintained or deprecated. Also, it loads 20+ different highlightjs-* packages, each from a different maintainer, significantly increasing the supply chain attack surface.

✅❓ Summary

Limited Recommendation. Planka feels “Enterprise-ready” in its documentation and deployment, but the custom license and technical debt tell a different story. If you need a simple, visual workflow and value the support of a German-based company (a plus for GDPR and maintenance), Planka is a solid choice. However, if you are seeking a truly sovereign, modern, and secure Jira replacement with deep Agile logic, Planka’s “Sails.js” foundation and restrictive license make it a difficult long-term bet.

Bridging the Gap: Integrating DevOps and ITIL

Peter Wurbs — Mon, 13 Apr 2026 10:59:03 +0000

The Challenge of Combining DevOps and ITIL

DevOps provides methods and tools to improve the agility, speed, and quality of software development. However, it lacks widely accepted guidelines for integrating these principles with IT Service Management (ITSM) operations.

But even in a fully implemented DevOps culture, we need service processes when we want to bring our product to customers and are obliged to provide service levels. We have to provide a support interface, implement alerting, fix issues, etc.

This article outlines a rough idea of how to bring these two worlds together. The ideas are based on ITIL, the leading framework for providing best practices to implement ITSM. Here we focus on ITIL v2/v3 and only take the main processes into account.

Unlike ITIL, DevOps has no such standardized framework. I assume you know what DevOps actually means. But to make sure we're all on the same page, here's my understanding in a nutshell:

DevOps is a cultural shift and collaborative approach that breaks down the traditional barriers to integrate everyone—including business stakeholders, security, operations, and quality assurance—into a single, organization-wide feedback loop. Instead of working in isolated silos, these groups join forces throughout the entire project, sharing responsibilities and communicating openly. This unified mindset allows organizations to respond to customer needs faster, solve problems more efficiently, and deliver continuous value.

TL;DR

For those who lack the time to read the entire content, here’s a concise summary of the approach:

The application of IT Service Management (e.g., ITIL) remains essential, even when DevOps practices are fully implemented.
At the very least, Incident, Problem and Event Management processes are required.
It is rarely feasible to implement all IT Service Management processes within the cross-functional DevOps team itself. Therefore, compromises must be made to delegate some tasks.
Practicing DevOps significantly impacts several classic ITIL processes, especially Change and Release Management.
Informal, manually maintained, and often outdated Configuration Management (CMDB) systems are replaced by current and accurate data obtained from various sources such as Issue tracking, Git, CI/CD, Cloud and software APIs, metrics, and logs.
Also see the diagram at the end of this article for a good summary.

The long Story

In the following, we go through the main ITIL processes and draw a rough idea of how these could be integrated into a DevOps way of work, respectively, how these are affected by practicing DevOps.

The well-known "You build it - You run it!" is the most relevant guideline. With every decision, you should consider how far you’re straying from this mantra.

Incident Management

It's the primary goal of Incident Management to restore IT services to users as fast as possible. This is the most challenging process to be integrated into a DevOps culture.

1st Level Support (Service Desk): Can be outsourced to specialized external organizations. Very often, these organizations provide standardized services (within a company) for many teams and products in a shared manner to reduce costs. The DevOps team provides troubleshooting guidelines and FAQs, while the external desk provides feedback on common incidents towards the DevOps team to improve the service.
2nd Level Support: Handles technical issues that do not require software developers. It can remain within the DevOps team to prevent silos, though offering 24x7 coverage is challenging. Alternatively, it can be outsourced for 24x7 support if tight collaboration is maintained, including shared tools, shared documentation, and deep technical education provided by the DevOps team. Often, this support level is also responsible for the deployment of the software into production. Here, it's especially crucial to achieve a tight collaboration, trust, and transparency to prevent further silos and borders. It's good practice to hold regular shared sessions to exchange information, knowledge, findings, and experiences. And it's a very good idea that some deputies of the 2nd level support take part in the daily stand-ups and the other regular meetings of the DevOps team. In this area, the risk of creating new silos is especially high.
3rd Level Support: It's crucial that this task remains within the DevOps team, because 3rd level issues are mostly related to software bugs and their troubleshooting, and their resolution must not be segregated from the software development. This responsibility also applies to 3rd level issues concerning the CI/CD pipeline and the deployment target environment. According to "You build it - you run it!" the team is also responsible for these topics.

Some general guidelines and tips:

All parties should use identical tools or at least automated data synchronization to prevent information loss. Incident tickets must be integrated into the DevOps team's daily agile planning (e.g., Kanban boards) and Sprint backlogs, utilizing reserved team capacity.
Engineers working on 2nd and 3rd level issues must be able to directly communicate with users and customers. Otherwise there is a loss of information and speed, which of course leads to bad support quality and unsatisfied users.
The DevOps team must reserve some velocity/resources for incident issues along with the sprint planning. A budget for this could be set initially, observed, and then adapted. If the budget is not fully used, then the team can use the remaining time to improve some ops-related topics like observability, stability, etc.
In the case where the production target environment (where the software runs) is operated by an external party, the DevOps team must get transparent and fast access to all configuration data, logs, metrics, and other relevant data. This is mandatory for the feedback loop and quick support in case of issues. See also below “Operating Target Environments”.

Event Management

Event Management ensures services are monitored and events are categorized for action. Nowadays, the old term "Monitoring" is usually replaced by the modern term "Observability" to reflect the versatile perspectives of modern software architectures (microservices, containers, cloud, etc.).

Data from observability tools are possible triggers for Incident, Problem, or Capacity Management and must be shared amongst all affected parties to avoid silos and borders.
As for Incident Management, the DevOps team needs direct access to all the data to support fixing or preventing issues as quickly as possible. Ideally, the DevOps team owns the concept and implementation for observability tools.
The old assumption that "monitoring" is "ops-stuff" is no longer valid. When we take "shift-left" seriously, then the DevOps team must integrate observability capabilities directly into the software architecture. The generated data provide vital business and runtime metrics and are not purely operational tasks. So, it's a good practice in the team to plan these aspects as early as possible in the software development lifecycle as part of the Non-Functional-Requirements (NFR).
Like for Incident Management, it's challenging for a DevOps team to watch the monitors 24x7. Also, for this, the team might delegate this to an external organization (e.g. together with the 2nd level support). But also here, the obligations for both parties apply.

Problem Management

Problem Management aims to prevent incidents and minimize their impact. The process is mostly triggered when a customer requests a RFO report (Reason for Outage) or (the proactive way), when the repeated occurrence of the same incidents must be investigated in order to prevent them in the future.

Because complex analysis is required, the execution of these tasks mostly falls to the 3rd Level Support within the DevOps team.
The above-mentioned guidelines regarding time budget, ticket management, and tools apply here too.

Capacity Management

This is the balancing act of ensuring that IT resources are exactly the right size—not too small (causing slow performance or crashes) and not too large (wasting money). We achieve good capacity management by:

an appropriate upfront resource planning
a suited configuration of the different items like servers, containers, applications, etc.
good observability (see Event Management)
a modern software architecture supporting horizontal scalability

As a result, this process should be owned by the DevOps team too. It has been one of the biggest failures in the past to delegate capacity planning to an operations team. This resulted in endless ping-pong between developers and ops.

Yes, if watching the monitors is delegated to e.g. the 2nd level support or any other "monitoring" team, then this team will see alerts and can act accordingly. But the DevOps team must own the concept, the thresholds, the resource configuration, and the instructions on how to act.

Configuration Management

Configuration Management in ITIL is intended to document information about Infrastructure and Services required for ITSM. So-called Configuration Items (CI) are available in a CMDB (Configuration Management Database) to support different ITSM processes.

We all know that it was never possible and has never worked to keep the CMDB up-to-date. Either there was not sufficient discipline, the tools were not appropriate, or the data changed too often. I can't remember any case that a CMDB was helpful. Data have been incomplete, outdated, stale, or not consistent. This becomes much more problematic when we move to the cloud, spin up 100 containers every day using ever-changing IP addresses, don't know exactly on which server or container which part of our (microservice-based) software runs, etc.

So, this process is the most affected and maybe even made obsolete by the modern (DevOps) world:

DevOps replaces manually maintained CMDBs with an "everything-as-code" approach. Target configuration states are stored in Git and directly used in our tool pipeline to build, test, and deploy.
This is combined with the retrieval of the current state of configuration directly from the involved systems and software using APIs, dashboards, logs, metrics, etc.

Request Fulfillment

This process manages minor, standardized changes (service requests) or requests for information from users.

Self-service for users should be provided as much as possible. This saves time, money, and makes users happy.
The 1st or 2nd Level Support should handle simple, standard requests using guidelines provided by the DevOps team.
Complex or non-standard requests must be delegated to the DevOps team.

Change Management

Like Config Management, this is another ITIL process becoming mostly obsolete when we truly practice DevOps. ITIL defines this process as a kind of gatekeeper of the IT environment. Its primary mission is to maximize the number of successful IT changes by ensuring that risks are properly assessed and authorized before they happen. Unfortunately, this ended up in the past by adding more and more formal processes, checkpoints, gateways, paperwork, etc. This all mostly decreased the speed of delivering new features to the users and imposed silos and barriers mostly between developers and operations. When a company is really ready to introduce a DevOps culture, many of the formal rules vanish.

All changes, including new features, infrastructure, or config changes, are treated as code changes (everything-as-code), passing through the agile development in the team and CI/CD pipelines with automated tests.
However, some truly important formal procedural steps should be retained. This is especially the case if the deployment has an impact on the users' perception or some risks must be mitigated. A pragmatic view on these process steps is required.

Release Management

Release Management ensures that new or modified IT services are planned, developed, and successfully deployed to the production environment. When we practice DevOps, this integrated view of release and deployment is decoupled.:

A deployment is the technical process to provide software into one of the target environments (dev, test, qa, prod...). Deployments should happen continuously in small pieces, ideally in the background (e.g., via dark launching) without user disruption. Only by this, the DevOps team gets valuable feedback from users quickly.
A "release" is the logical provisioning of software, new features, etc., to users. The technical deployment has ideally already been done, see before. During release, only small activation tasks might be done, like config changes or ingress adaptions. Release Management is thus reduced to bundling feature sets while organizing a product roadmap and external communication.

What does this mean for the DevOps team?

The DevOps team should be responsible for the deployment concept, the preparation of the toolchain to execute deployments, and provide sufficient information if the actual deployments are done by an external organization.
It's clear that the Product Owner is responsible for the actual Release process.

Operating Target Environments

Finally, we must ask, which party should "operate" the target environments, where the software actually runs. We only touched it briefly in Incident Management. The classic answer has been in the "old" world: There is an operations department taking care of these environments. As a result, again, we have silos and borders. By the way, these borders have been the reason why DevOps was invented more than 10 years ago. So, let's invest some final minutes to ask how it could work in a DevOps world.

Again, ideally, the DevOps team has the resources and knowledge to deal with the target envs too. Then, the team can optimally combine software, infrastructure, deployments, and operations without any borders, gaps, or quarrels.

But in most cases (e.g. due to company restrictions), the target envs are operated by an external team. This is fine, but then...

the DevOps team keeps responsible for the infrastructure, deployment, and observability concept.
the DevOps team provides all required documentation, instructions to enable the external "ops" team.
the DevOps team must get transparent and fast access to all configuration data, logs, metrics, and other relevant data. This is mandatory for the feedback loop and quick support in case of issues.

It's also a good approach to distinguish between dev and prod environments. Even if the operation of the prod target is externally delegated, the non-prod targets, especially dev environments, should still be maintained by the DevOps team itself. Even a shared operation is possible. See the picture below for more details.

Summary Diagram

Final Note

As an alternative framework, Google's Site Reliability Engineering (SRE) is often cited as a highly effective best practice for bridging the gap between DevOps and ITIL/Operations.

Links to my Articles and Repos

Peter Wurbs — Mon, 13 Apr 2026 10:49:56 +0000

Articles

Repos

wuFlow is a simple, modern, and lightweight issue tracking and planning application.
max2mqtt is a MAX! to MQTT Bridge Home Assistant Add-on.

How to integrate SonarQube (SonarCloud) for free without loosing Control over my Code

Peter Wurbs — Tue, 27 Jan 2026 10:08:16 +0000

How to integrate SonarQube (SonarCloud) for free without loosing Control over my Code

Intro

There are already some posts that explain how to use SonarQube and SonarCloud, along with their related scanners, in general. However, these posts either don’t cover the integration aspects, are quite old, or don’t address my specific questions. So, I’ve decided to embark on my own journey and share my insights here.

Goal

I’m privately developing some applications and, at some point, I wanted to use Static Source Code Analysis to check my code. Since I work in this field, I was already familiar with SonarQube and was quite satisfied with its results. However, I don’t currently have a proper license, and I’m not comfortable sharing too much control over my data or code. Therefore, my goals and restrictions are as follows:

Scan Go, JS, CSS, HTML
Integrate in Visual Studio Code
Keep control as much as possible
Provide nice comprehensive reports and statistics
Stay independent on a concrete public Git registry

TL;DR

For those who lack the time to read the entire content, here’s a concise summary:

The "Safe" SonarCloud Account Setup

Registration: You cannot sign up with just an email. You must use another account like GitHub.
Privacy Trick: To keep control over your code, authorize the SonarCloud GitHub App only for a single "Dummy/Empty" repository.
Project Creation: Inside SonarCloud, do not "Import" from GitHub. Instead, choose "Create a project manually." This creates an "Unbound" project that waits for you to push data to it, rather than SonarCloud pulling data from a repo.

Scanning Strategies

There are two distinct tools because they serve different purposes. Neither one can replace the other.

Tool	SonarQube vscode plugin	sonar-scanner CLI
Purpose	Instant feedback ("Spell checker") while typing	Full project health report & Dashboard update
Scope	Only open files	The entire repository
Data Flow	Downloads rules from Cloud when Connect mode configured No code upload.	Scans locally → Uploads report to SonarCloud.
Trigger	Automatic (Real-time).	Manual (Command Line).

The final Workflow

Code: You write code in vscode. The plugin (in Connected Mode) underlines issues using SonarCloud rules.
Commit: You commit your changes to Git.
Repo scan: You run the scanner CLI command in your terminal or in a CI/CD pipeline to scan the whole repo and upload the results to SonarCloud.
Reports: You check the results in SonarCloud.

The long Story

Start

Apparently, I was thinking too simply. I thought, I only would have to register for a free developer account at SonarQube Cloud (SonarCloud), create a project with a token there, install the SonarQube vscode plugin, create the connection to the SonarCloud via the token, and that's it. Hopefully, the code stays locally, only scan results are transferred to the cloud and stored there for nice reports and statistics. Far from it...

Register at SonarCloud / Grant access to GitHub

SonarCloud doesn't provide the usual email address-based register option. They force us to use one of the public or private Git repo providers. If it were only about authentication, then it would be okay. But SonarCloud wants to get read/write access to the repos in my GitHub account. At least it can be limited to a single repo.

The intention behind is clear. SonarCloud strongly integrates into the GitHub repo and executes all scans directly on the code there. But this requires granting write permissions in this repo. So, you have to trust Sonar. Currently, I wouldn’t do this. Even if SonarQube is still partly open source and there is a kind of community edition, I would not bet that it’s forever. And we have seen several times what happens with our code when we are too lazy. Anyway, I don’t want to grant this kind of trust and permissions on my code repo.

So, what else can I do? To at least finish the registration at SonarCloud, I created a dummy repo in GitHub and granted access only to this repository. As a result, SonarQube Cloud is now listed in GitHub Applications under both “Authorized GitHub Apps” and “Installed GitHub Apps”.

I don’t really understand why 2 entries are needed. Even the dedicated GitHub documentation is not that clear and a bit misleading. As a result of my studies, I assume the former is for using GitHub as an OAuth provider to log in to SonarCloud. The latter defines how SonarCloud is entitled to access my GitHub repo(s). When you click on the Configure button, you can configure the repos to which SonarCloud shall get access. Finally, I found out that the entry at "Installed GitHub Apps" and the dummy repo can be deleted. So, (hopefully) only the OAuth authorization remains. If your are still unsure, create a separate fully isolated GitHub account to handle SonarCloud registration and authentication. Maybe, you need the account for other cases like this.

But it’s clear: If you don’t grant access to the actual code repo but only to a dummy repo to get the registration done, then your actual code won’t be scanned by SonarCloud directly on the GitHub repo. This is intended in my personal case.

This means that we must manage to interconnect SonarCloud with local software by any way. Here, the actual journey starts. We must understand the different elements at the local side, how they interact with each other, and what added value each of them provides. Then we can decide, what we really want to install and use.

The Components

I read many pages, tried some things out, and asked AI. As a result, I got an overarching picture of how the whole stuff can be put together. To explain any further, I will describe the involved components, their purpose, and added value.

The local code repository and shell

This is easy. This is the local code on your machine which shall be scanned and evaluated. And there is a shell terminal, where commands can be executed.

The remote repo

If you work on a serious project, you will push your code to a kind of remote Git repository. This can be a privately hosted Git server or most usually a public repo like GitHub or Codeberg (here, either a public or private repo). Because I stated that I don't want to tightly integrate my remote repo with SonarCloud, the remote repo is not involved in the further concept. (Even though if I push my code to one of these repos too.)

The SonarCloud

This provides the features of SonarQube as a cloud service. The features are pretty much the same compared with the self-hosted SonarQube, but of course, pricing, licenses, and subscription plans differ. You can set up different organizations and projects. Each project can cover different Git repos.

To create a new project in SonarCloud, click on the plus sign in the top right corner, select "Analyze new project", and then resist to select a GitHub repo when you want to keep control (like me). Instead, use the small link on the right side "create a project manually". This is the crucial step to setup a SonarCloud project which is not bound to a repo on GitHub or similar.

It's possible to centrally configure sonar scan properties, quality profiles and gates and much more. In the Free plan, built-in rules and gates must be used. These configuration settings will apply when you either:

bind a project to a GitHub repo (what I don't want)
install the SonarQube plugin into vscode and setup the Connected Mode (see below)
run the sonar-scanner locally and push the results to SonarCloud (see below)

SonarCloud provides nice reports about different aspects of software quality. The main areas are general code quality, security, and test coverage. Reports are shown for new and overall code, branches are distinguished, and even a trend can be visualized.

But presenting these nice reports require that any scan results are delivered to SonarCloud. This can be done by:

direct repo binding (again, not preferred)
local execution of the sonar-scanner including push of the results to the cloud

It's essential to understand that the SonarQube plugin for vscode doesn't deliver scan results to SonarCloud even not in the Connected mode. This plugin has a different purpose, see below. Executing the sonar-scanner CLI is required for this. This was my main misunderstanding when I started the journey.

In general, SonarCloud is really useful when you want to work in a team, consolidate quality properties, have a common view on the quality status, and see the trend over the software lifecycle.

But even if you are "only" a single developer, it is really useful to have this kind of insights into your software quality.

And when you don't want to use the cloud service, then deploy your self-hosted instance of SonarQube. But you have to pay some money to get the full palette of features.

The SonarQube plugin for vscode

This plugin checks your code while you type. Issues are visualized in your code editor and in the Problems window. When you click in a marked code, you get explained what's wrong and how it can be fixed.

When you configure the connected mode (see https://docs.sonarsource.com/sonarqube-for-vs-code/connect-your-ide/connected-mode), then only any centrally managed scan configuration is pulled from SonarCloud to your local machine. This allows you to ensure that any team member uses the same configuration even when locally applied.

This is what the plugin does not:

It doesn't scan the whole code in your local repo. It only works on the open file. The "Problems" window only contains issues for open files.
It doesn't deliver scan results to SonarCloud even not in the Connected mode. This plugin has a different purpose to support you while working on your code.

The sonar-scanner

This is the most useful tool when you want to check your software completely and locally. Best, you download the binary from the SonarCloud website. Go to a Project → Administration → Analysis Method → Manually. Then you can select your OS, etc., and get a download link and some additional information on how to run the sonar-scanner. Especially, you get config information on how to push sonar-scanner results to SonarCloud and how to deal with the auth token.

If this has been set up, simply execute the sonar-scanner in your local terminal. It scans the whole repo, which takes about 30 seconds for 4.5k lines of code. As part of the execution, the results are delivered to SonarCloud where the results can be seen and assessed. In contrast to the vscode plugin, this scan also contains some more complicated security-relevant checks.

If sonar-scanner is configured to use SonarCloud, it pulls quality profiles, quality gates, and general settings. But any local configuration sonar-project.properties file (see the code example below) would have precedence over configuration in SonarCloud. This applies especially for code-relevant settings like file exclusions, inclusions, unit test settings, etc. It's recommended to keep these config items in the local file under Git control rather than managing it in the SonarCloud UI.

To automate the execution of sonar-scanner along with e.g. test and build steps, it's good practice to create a tasks.json in vscode (see code example below).

When a CI/CD pipeline like Gitlab, Jenkins, Woodpecker, or GitHub Actions is used, then the execution of the sonar-scanner should be an integrated part of the build and test process.

You could ask if we still need SonarCloud at all if we can execute the local sonar-scanner. Unfortunately, yes! If you run sonar-scanner without a configured and reachable Sonar server (either SonarCloud or a local SonarQube instance), the scan will fail. It does not produce a standalone HTML or PDF report on your hard drive. Sonar works on a client-server architecture:

The Scanner (Client): Its only job is to read local files, extract some data, and ship data files to the server. It does not calculate the final results or aggregate the issues itself.
The SonarCloud (Server): This is where the heavy work happens. The server processes the raw data, applies the rules, calculates "New Code" deltas, and generates the visual report.

Overarching Diagram

This self-made diagram tries to depict the overall relations, without GitHub or similar.

Decision Options

Based on all these facts, what options do we have now:

The "magic" option: Bind your project/repo in SonarCloud directly to a Git repo at e.g. GitHub. Some magic happens now: Sonar gets notified when there is a commit to GitHub, clones the repo, and executes the scan. Additionally, use the vscode plugin, and for special cases, execute sonar-scanner as part of your CI/CD pipeline.
The "fully on my own" option: Don't use SonarCloud at all. Only install the SonarQube plugin for vscode without connected mode to scan your code while you are typing. You get instant feedback on your code. Optionally, you can deploy your self-hosted instance of SonarQube and execute sonar-scanner connected to this instance.
The "pragmatic" option: Use SonarCloud, but don't bind to a GitHub repo. Instead, set up a "manual" project in SonarCloud. Install the vscode plugin using connected mode for instant feedback in your IDE. Execute sonar-scanner locally and/or via CI/CD pipeline against your manually set-up SonarCloud project.

→ For the time being, I decided for option 3. It's a good balance between code control, convenience and results.

Code Examples

.vscode/settings.json → local config file for vscode plugin

{
  "sonarlint.connectedMode.project": {
    "connectionId": "connection_name",
    "projectKey": "sonarcloud_project_key"
  }
}

sonar-project.properties → local sonar-scanner configuration

# This tells the scanner: "Send the results to the Cloud, not Localhost"
sonar.host.url=https://sonarcloud.io

# Uniquely identifies your project on SonarCloud
# You get these from the project Information page on SonarCloud
sonar.organization=sonar_org
sonar.projectKey=sonarcloud_project_key

# Source code location. 
# "." means "everything in this directory"
# we exclude some files and folders later
sonar.sources=.

# Exclusions (Optional)
# Don't scan build results and database files
sonar.exclusions=bin/**,*.db*

# Specify test files
sonar.tests=.
sonar.test.inclusions=**/*_test.go

# Test coverage report
sonar.go.coverage.reportPaths=coverage.out
sonar.coverage.inclusions=backend/**/*.go
# the inclusion is not sufficient to exclude static files, so we need to exclude them explicitly
sonar.coverage.exclusions=static/**/*,main.go

.vscode/tasks.json → automation file for test, build and scan

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "1. Go Test",
      "type": "shell",
      "command": "go test -v -coverprofile=coverage.out ./backend/...",
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "shared"
      },
      "problemMatcher": [
        "$go"
      ]
    },
    {
      "label": "2. Go Build",
      "type": "shell",
      "command": "go build -v main.go",
      "group": "build",
      "presentation": {
        "reveal": "always",
        "panel": "shared"
      },
      "problemMatcher": [
        "$go"
      ]
    },
    {
      "label": "3. Sonar Scanner",
      "type": "shell",
      "command": "sonar-scanner",
      // Use a login interactive shell to ensure the user's PATH and SONAR_TOKEN are loaded correctly (finding sonar-scanner binary)
      "options": {
        "shell": {
          "args": [
            "-l",
            "-i",
            "-c"
          ]
        }
      },
      // Add your specific arguments here if not using a sonar-project.properties file
      "args": [
        "-Dsonar.token=${env:SONAR_TOKEN}" // we keep it here to document that the envvar is used
      ],
      "presentation": {
        "reveal": "always",
        "panel": "shared"
      },
      "problemMatcher": []
    },
    {
      "label": "Run Full Pipeline",
      "dependsOn": [
        "1. Go Test",
        "2. Go Build",
        "3. Sonar Scanner"
      ],
      "dependsOrder": "sequence",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "problemMatcher": []
    }
  ]
}