Why we're All-in on GitHub
?1761549859100)
Specificy Drives Better Features and Faster Time-to-Value
October 1, 2025
Last year, my co-founders and I met in-person to explore what the "next-generation" features for an Internal Developer Platform would be. We came up with a ton of ideas including 1-click infrastructure and software deployments that were easy to build, integrations to all major SCMs/DevOps/documentation platforms, even things like predictive cloud spend analysis.
We actually started off by building a large-scale, highly-customizable job runner system that would work in the cloud and on-premises. While building the bones of our application, we kept running into architectural issues that would have direct implications for our platform. For example, GitHub, GitLab, BitBucket, and other SCMs handle Git repositories, code contributions, users, permissions, and issue tracking differently.
If we were to support all of those platforms in a streamlined way, we would need to reduce the depth of features we could provide. It also made onboarding incredibly complex - simply creating your account and integrating with your SCM meant at least 3 separate integrations, complex instructions, and different experiences. This made everything feel too complex.
Instead, our Engineering Lead proposed the idea that we'll focus on GitHub and integrate with their platform as tightly as possible and we've been all-in ever since. Natively supporting GitHub simplified our API, job runner system, GenAI prompts, tools, and the onboarding experience. Instead of supporting multiple systems, we can provide a well-defined and streamlined experience for any company that uses GitHub.
To be more precise, this is how being GitHub-Native benefits our users:
- Creating an account takes seconds because installing GitHub apps is an easy process
- Our machine learning algorithms efficiently analyze your service boundaries to automatically setup your account structure and service catalog
- The entire flow of creating changes in the app mirrors GitHub's pull request process and leverages tools including GitHub Copilot and GHAS
- We streamlined providing context to our GenAI agent so it can execute across hundreds or thousands of GitHub repositories in parallel
- Every construct our platform creates works natively in GitHub
- We inherit your GitHub organization's permissions model for platform RBAC
- We fine-tuned workflow compliance testing to align to GitHub Workflow best-practices
- We built workflow migration logic so you can easily convert your Jenkins, Azure DevOps, GitLab, or other automations into GitHub Actions Workflows at scale using our Expert Migration Assistant
What does all of this mean?
If you are a GitHub user, you're going to have the experience of a lifetime. Setting up your account is incredibly quick. CodeCargo will automatically generate your project structure so it aligns with your service boundaries. Our Expert Compliance Agent will score every single workflow to proactively identify remediations to ensure security and compliance. You can designate your existing workflows as "Golden Paths" with 4 button clicks. You can create a fully-customized self-service workflow for your developers to consume in about 2 minutes. You can create hundreds of PRs in parallel to perform migrations or bulk security fixes.
Being "all-in" on GitHub means we are giving you the power to turn 1 developer into 10.
C
CodeCargo Team
The CodeCargo team writes about GitHub workflow automation, developer productivity, and DevOps best practices.
