
In the world of software development, the ultimate testament to a platform's capability is often whether its own creators rely on it for their most critical tasks. For GitLab, the comprehensive DevSecOps platform, this isn't just a talking point—it's a fundamental operational reality. GitLab runs its entire company, develops its vast software, manages its complex infrastructure (including GitLab.com), and fosters its all-remote culture using its own single application. This profound commitment to "eating your own dogfood," or as they often put it, "GitLab on GitLab," is not just a practice; it's a core tenet that shapes the product, drives innovation, and ensures a deep empathy with its global user base.

### The Entire Company Runs on GitLab: A Single Source of Truth

GitLab's vision, as often articulated by CEO Sid Sijbrandij and reflected in their extensive [public handbook](https://handbook.gitlab.com/handbook/), is to provide a single application for the entire software development lifecycle. This vision is most powerfully validated by their own internal adoption. From idea to production, GitLab uses GitLab for:

* **Source Code Management:** The millions of lines of code that constitute GitLab itself are managed in GitLab repositories. Every merge request, every code review, and every version iteration happens within their own platform.
* **Continuous Integration/Continuous Deployment (CI/CD):** GitLab's robust CI/CD capabilities are the engine behind their own development velocity. They use GitLab CI/CD to automatically build, test, package, and deploy GitLab.com and its various components multiple times a day. The [GitLab Handbook page on "Dogfooding CI/CD"](https://handbook.gitlab.com/handbook/engineering/infrastructure/library/ci-cd/) provides a glimpse into how seriously they take this internal proving ground.
* **Plan and Project Management:** All work, from strategic initiatives and new feature development (organized via Epics, Issues, and Iterations) to marketing campaigns and HR projects, is planned, tracked, and managed using GitLab's own planning tools. This ensures that these features are robust and genuinely useful for diverse team workflows.
* **Security (DevSecOps):** GitLab champions a "Shift Left" security approach, and they apply this to their own development by integrating their suite of security scanning tools (SAST, DAST, Dependency Scanning, Secret Detection, etc.) directly into their CI/CD pipelines. This internal use is critical for refining these DevSecOps capabilities.
* **Collaboration and Communication:** As a pioneering all-remote company with team members in over 65 countries, asynchronous communication and transparent collaboration are vital. GitLab (the product) serves as the central hub. Merge requests are key collaboration points, issues track discussions, and the entire company handbook—a sprawling, living document of over 2,000 pages detailing how they operate—is a GitLab project, open to contributions and iterations from all team members. This transparency, a core GitLab value, is enabled by their own platform.
* **Operating GitLab.com:** The SRE (Site Reliability Engineering) and infrastructure teams responsible for the massive GitLab.com SaaS offering use GitLab's monitoring, deployment, and incident management capabilities to keep the service running. This is arguably the most demanding "dogfooding" environment, pushing the platform to its limits in terms of scale and reliability.

### How "GitLab on GitLab" Drives Product Evolution

This deep immersion in their own platform provides a continuous, high-fidelity feedback loop that directly shapes the product:

* **Real-World Problem Solving:** When GitLab's own engineers encounter a bottleneck in their CI/CD pipelines, a missing feature in issue tracking, or a cumbersome aspect of code review, they are experiencing the same pain points their users might. This creates a powerful internal impetus to build solutions that address these real-world needs.
* **User-Centric Design for Developers:** Because GitLab's primary internal users are developers, DevOps engineers, and product managers, the platform naturally evolves to meet the sophisticated demands of technical users who value efficiency, automation, and a comprehensive toolset.
* **Rapid Iteration:** With a monthly release cycle ("every month on the 22nd," as highlighted by [Sid Sijbrandij in an InfoQ interview](https://www.infoq.com/articles/gitlab-sid-interview-sw-development/)), the ability to quickly test and validate new features internally is crucial. "GitLab on GitLab" allows for rapid iteration based on immediate internal feedback.
* **Feature Prioritization:** The features that solve the most significant internal pain points or unlock substantial productivity gains for GitLab's own teams are often strong candidates for broader development and release.
* **AI Integration (GitLab Duo):** As GitLab integrates AI capabilities across the DevSecOps lifecycle with GitLab Duo (e.g., AI-assisted code suggestions, vulnerability explanations, value stream forecasts), its own teams are among the first to utilize and refine these tools in their daily workflows, shaping the future of AI-powered software development from within.

### The All-Remote Context: Shaping a Platform for Distributed Teams

GitLab's all-remote culture is not just a work style; it's a product shaper. Because the entire company collaborates and builds software without a central physical office, the GitLab platform has been inherently designed and optimized for asynchronous workflows, clear communication trails (via issues and merge requests), and transparency. This makes it an exceptionally strong platform for other distributed teams and organizations embracing remote or hybrid work models. Their [All-Remote guide](https://about.gitlab.com/company/all-remote/) is a testament to their expertise, and the platform reflects these ingrained practices.

### Benefits of a Transparent, Dogfooding Culture

The "GitLab on GitLab" approach, coupled with their commitment to transparency (much of their handbook and roadmap are public), yields significant benefits:

* **Authenticity and Trust:** Users and customers can see that GitLab believes in its own product enough to run its entire business on it.
* **High-Quality, Battle-Tested Features:** Features are rigorously tested in a demanding, real-world environment before reaching the wider community.
* **Deep Understanding of User Needs:** GitLab developers have an intrinsic understanding of the challenges and desires of other software development teams.
* **Strong Community Alignment:** By being open about their processes and using their own product, they foster a strong connection with their open-source community.

While the primary users within GitLab are highly technical, the company also focuses on making the platform accessible. However, the depth and breadth of features, as noted in some external analyses like a [SentinelOne article on GitLab CI/CD Security](https://www.sentinelone.com/cybersecurity-101/cloud-security/gitlab-ci-cd-security/), can sometimes present a learning curve for new users—a common challenge for comprehensive platforms that GitLab likely continuously addresses through documentation and UI refinements based on broad feedback.

### Conclusion: The Ultimate DevOps Proving Ground

GitLab's commitment to using its own platform for every facet of its operations is a powerful demonstration of confidence and a critical driver of its innovation. By making its own teams the first and most demanding users, GitLab ensures that its DevSecOps platform is not just a collection of features but a deeply integrated, battle-tested solution designed to meet the real-world challenges of modern software development. The "GitLab on GitLab" philosophy means that when users choose GitLab, they're adopting a platform that is continuously shaped and validated by a global team of experts who don't just build the future of DevOps—they live it every day.

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration


Atlassian's mission is to "help unleash the potential of every team." This ambitious goal is pursued not just by creating powerful collaboration and project management software like Jira and Confluence, but by deeply embedding these tools into the very fabric of their own global operations. The practice of "eating your own dogfood"—or as it might be termed, "Atlassian on Atlassian"—is a cornerstone of their product development philosophy. By having their own diverse teams rely on Jira for everything from software development and IT support to marketing campaigns and HR processes, Atlassian gains unparalleled insights that continuously shape and refine the tools used by millions worldwide.

### Jira as the Central Nervous System for Atlassian

From its origins as a bug tracker, Jira has evolved into a versatile platform catering to various team needs, with specialized versions like Jira Software for agile development, Jira Service Management for IT and customer service teams, and Jira Work Management for business teams. Atlassian itself is a living testament to this versatility, utilizing the entire Jira family, alongside integrated tools like Confluence for knowledge management and Bitbucket for code hosting, across virtually every aspect of its operations.

* **Building Jira with Jira:** Atlassian's own software development teams are quintessential Jira Software users. They leverage its agile boards (Scrum and Kanban), backlog management, sprint planning, bug tracking, and reporting features to build, iterate on, and maintain Jira itself, as well as other Atlassian products. This intensive internal use by thousands of engineers provides a constant, real-world stress test and a rich source of feedback for improving performance, usability, and developer-centric features.
* **Powering Internal Service Desks:** Atlassian's IT and support teams utilize Jira Service Management for their internal help desks, managing employee requests, resolving incidents, and handling change management processes. This firsthand operational experience directly informs the development of JSM, ensuring it meets the practical needs of service teams in a high-velocity environment.
* **Orchestrating Business Team Projects:** Non-technical teams across Atlassian—including marketing, HR, finance, and legal—use Jira Work Management and other Atlassian tools to plan projects, track tasks, and collaborate. This broad internal adoption ensures that Jira's capabilities evolve to support a wide array of business workflows, not just software development.
* **Knowledge Sharing and Collaboration:** Confluence is deeply integrated with Jira and serves as Atlassian's central knowledge base. Internal teams document product specifications, project plans, meeting notes, and company policies in Confluence, all linked to and tracked within Jira. This seamless interplay is refined through their own daily collaborative practices.

### The "Dogfooding" Culture: Feedback from Every Corner

Atlassian's company values, such as "Open company, no bullshit" and "Play, as a team," foster an environment where internal feedback is encouraged and valued. This culture is crucial for effective "dogfooding."

In an [Atlassian Community discussion on dogfooding](https://community.atlassian.com/forums/Teamwork-Lab-questions/Ask-Me-Anything-DOGFOODING-best-practices-pitfalls-and-personal/qaq-p/1797710), Atlassian employees openly share insights into their internal practices. One employee noted, "By moving all of our communications within Atlassian products and making it a requirement our teams/team members have become more accountable to each other." Another shared, "It is true that internal Atlassian teams are encouraged to adopt new features and capabilities but is rare that we force them to (unless we are doing a forced migration and then Atlassian teams go earlier to test the migration process itself)."

This highlights a balanced approach where organic adoption is preferred, but strategic internal rollouts also serve as crucial testing phases. The same discussion revealed that successful internal projects during "ShipIt" (Atlassian's hackathon days), aimed at solving internal pain points with their own tools, have sometimes led to those features being incorporated into the official product roadmap. Examples cited include the "dot dialog for quick shortcuts in Jira, Confluence page layouts, find and replace in the editor."

### How Internal Use Shapes Jira's Evolution

The direct impact of Atlassian employees using their own tools is evident in many aspects of Jira's development:

* **User Experience (UX) and Usability:** Constant daily interaction by thousands of "Atlassians" with diverse roles and technical abilities helps identify usability friction points and areas for UI refinement. Feedback on aspects like the [Jira Software issue view](https://community.atlassian.com/forums/Jira-articles/An-update-on-Jira-Software-customer-feedback-June-2022/bc-p/2076702) is taken seriously, leading to improvements in efficiency and ease of use.
* **Workflow Customization and Flexibility:** Because Atlassian teams use Jira for a vast array of different processes, the platform has evolved to offer highly customizable workflows, issue types, and fields, allowing it to adapt to myriad use cases—a flexibility born from their own diverse internal needs.
* **Integration Capabilities:** The need for seamless information flow between different internal teams and tools (e.g., Jira with Confluence, Bitbucket, and third-party applications) drives the development of robust integration capabilities.
* **Agile at Scale:** As Atlassian itself has grown into a large, distributed organization, its experiences in managing agile development at scale have undoubtedly influenced features in Jira Software designed to support larger enterprises and complex project portfolios, such as Advanced Roadmaps.
* **AI-Powered Enhancements:** With the introduction of Atlassian Intelligence and AI-driven features like Rovo, it's certain that Atlassian's own teams are among the first to leverage these capabilities for tasks like summarizing issues, generating content in Confluence, and automating workflows. This internal adoption is crucial for refining these AI tools and ensuring they deliver tangible productivity benefits. Atlassian's [Team '25 conference previews](https://www.computerweekly.com/blog/CW-Developer-Network/What-to-expect-from-Atlassian-Team-25) indicate a strong focus on AI-powered teamwork, a direction likely validated by internal use cases.

### The Benefits and a Balanced Perspective

Running "Atlassian on Atlassian" offers clear advantages:

* **Deep Customer Empathy:** Atlassians experience the product as users, fostering a profound understanding of customer needs and pain points.
* **Improved Product Quality:** Internal teams act as a constant, rigorous testing ground, catching bugs and usability issues early.
* **Faster Innovation Cycles:** The tight feedback loop between internal users and development teams can accelerate the iteration and improvement of features.
* **Authentic Product Advocacy:** Employees who use and believe in their own tools become powerful and authentic advocates.

However, as acknowledged in the Atlassian Community discussion on dogfooding, internal users may not always perfectly represent the full spectrum of external customers, particularly those with different technical skills or organizational contexts. Atlassian mitigates this by complementing internal feedback with extensive customer research, community engagement, and dedicated user testing programs. They also recognize that sometimes teams might adapt their processes to fit the tool, and strive to learn from instances where even internal teams might use a competitor's product for specific needs.

### Conclusion: Building for Teams, By a Team Living Its Products

Atlassian's commitment to using its own suite of tools, with Jira at its core, is a fundamental aspect of its identity and success. It’s a continuous, company-wide "dogfooding" effort where every employee contributes to the refinement of the products they build by using them to do their own work. This deep, practical immersion ensures that Jira and the broader Atlassian platform are not just designed with teams in mind, but are actively shaped by the daily experiences, challenges, and innovations of one of the most dynamic and collaborative teams in the software industry: their own.

Unleashing Team Potential from Within: How Atlassian Builds Jira by Living in Jira


HashiCorp has carved out a significant niche in the software world, providing essential open-source and commercial tools that empower organizations to provision, secure, connect, and run their cloud infrastructure. With powerhouses like Terraform for infrastructure as code, Vault for secrets management, Consul for service networking, and Nomad for application orchestration, one would expect HashiCorp to be an ardent user of its own product suite. Indeed, the company's philosophy and the interconnected nature of its tools suggest a deep internal reliance that inevitably shapes their development.

While HashiCorp may not have an extensive public library of "we eat our own dog food" case studies in the traditional marketing sense, the evidence of their internal usage and its impact is apparent. The company champions "The Infrastructure Cloud," a concept promoting a unified platform for managing the entire lifecycle of infrastructure and security resources. This vision itself implies that HashiCorp's teams would be the first and most critical users, ensuring these tools work harmoniously and effectively at scale.

A particularly insightful example comes from the operational experience of their Terraform Cloud service. As detailed in a discussion about "[Using Temporal at Hashicorp](https://temporal.io/resources/on-demand/temporal-hashicorp)," the Terraform Cloud team initially ran their services on large Nomad clusters. However, they encountered significant "blast radius" issues, where a problem in a single large cluster could impact all customers. This real-world operational challenge, using their own Nomad for a critical service, led them to re-architect their systems. They implemented a cellular architecture with shuffle sharding to mitigate this risk, breaking down the infrastructure into smaller, isolated Nomad clusters.

Interestingly, to manage these now numerous Nomad clusters effectively and orchestrate complex workflows, HashiCorp turned to an external tool: Temporal. They even went on to build an internal "Compute API" using Temporal to allow their teams to manage workloads across these Nomad clusters in a self-service manner. This decision is a hallmark of a mature engineering culture – one that leverages its own tools where they shine but isn't afraid to integrate best-of-breed external solutions to solve specific, complex problems that arise from using their own products at scale. The lessons learned from managing Nomad in such a demanding, multi-tenant environment undoubtedly feed back into Nomad's own development, future features, and best-practice recommendations for users facing similar scaling challenges.

Beyond this specific, documented instance, the general development and integration of the HashiCorp stack point to extensive internal use:

* **Integrated Ecosystem:** Tools like Consul-Terraform-Sync, which automates network infrastructure based on Consul's service discovery, or the tight integration between Vault and other HashiCorp products for secure credential injection, are indicative of a development process that understands the real-world interplay between these components. Such integrations are best forged and refined through firsthand operational experience.
* **Addressing Complexity:** HashiCorp's products tackle inherently complex domains. Vault, for instance, while incredibly powerful for secrets management, is often cited by users for its "Complex Setup and Configuration" and "Steep Learning Curve" ([Configu, "HashiCorp Vault: 6 Alternatives & Competitors You Should Know"](https://configu.com/blog/hashicorp-vault-6-alternatives-competitors-you-should-know/)). It's reasonable to assume that HashiCorp's own engineers encounter these complexities. This internal friction can be a powerful driver for improving documentation, streamlining workflows, enhancing user interfaces, and developing better operational patterns for their products – benefiting the entire user community.
* **Open Source Ethos:** HashiCorp's strong roots in open source mean their tools are scrutinized and contributed to by a vast community. However, the core development and vision are steered by HashiCorp. Being primary users of their own open-source tools allows their internal teams to act as "customer zero," identifying critical bugs, usability issues, and feature gaps long before they might be reported by the wider community. This helps in "enabling practitioners," a core tenet mentioned on their website ([HashiCorp, "Open Source and HashiCorp"](https://www.hashicorp.com/about/open-source)).

However, this internal usage isn't without its potential blind spots. When a company becomes deeply enmeshed in its own ecosystem, there's always a risk of developing solutions that are highly optimized for their specific internal way of working, potentially missing broader market needs or alternative approaches. The decision to use Temporal, in a way, highlights a recognition of this; rather than trying to force-fit or build a less suitable internal solution for workflow orchestration at that scale, they adopted an external tool.

Furthermore, the primary focus of HashiCorp's tools on infrastructure and platform teams within often large organizations means their internal usage might not always reflect the experience of smaller teams or individual developers who might find the operational overhead of some tools challenging.

In conclusion, HashiCorp's journey of building and using its own foundational infrastructure tools is a compelling narrative. The internal operational stresses, particularly those encountered by services like Terraform Cloud running on Nomad, provide invaluable, real-world feedback loops that are crucial for refining these powerful but complex products. While they don't shy away from adopting external tools like Temporal when it makes engineering sense, their core existence as a provider of infrastructure automation and security tools necessitates a deep, ongoing internal reliance. This self-referential development process, born out of necessity and a desire to solve their own infrastructure challenges, ultimately benefits the wider ecosystem of users who depend on HashiCorp to "do cloud right."

Articles tagged with "Devops"

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration

Unleashing Team Potential from Within: How Atlassian Builds Jira by Living in Jira

HashiCorp: Building the Builders' Tools, And Learning From Within