Author name: ITMAITY

Updated February 5, 2025: The post contains 50 new customer stories, which appear at the beginning of each section of customer lists. The post will be updated regularly with new stories. One of the highlights of my career has always been connecting with customers and partners across industries to learn how they are using technology to drive their businesses forward. In the past 30 years, we’ve seen four major platform shifts, from client server to internet and the web to mobile and cloud to now — the next major platform shift to AI.   As today’s platform shift to AI continues to gain momentum, Microsoft is working to understand just how organizations can drive lasting business value. We recently commissioned a study with IDC, The Business Opportunity of AI, to uncover new insights around business value and help guide organizations on their journey of AI transformation. The study found that for every $1 organizations invest in generative AI, they’re realizing an average of $3.70 in return — and uncovered insights about the future potential of AI to reshape business processes and drive change across industries. Check out the top 5 AI trends to watch from IDC and Microsoft Today, more than 85% of the Fortune 500 are using Microsoft AI solutions to shape their future. In working with organizations large and small, across every industry and geography, we’ve seen that most transformation initiatives are designed to achieve one of four business outcomes:   Enriching employee experiences: Using AI to streamline or automate repetitive, mundane tasks can allow your employees to dive into more complex, creative and ultimately more valuable work. Reinventing customer engagement: AI can create more personalized, tailored customer experiences, delighting your target audiences while lightening the load for employees. Reshaping business processes: Virtually any business process can be reimagined with AI, from marketing to supply chain operations to finance, and AI is even allowing organizations to go beyond process optimization and discover exciting new growth opportunities. Bending the curve on innovation: AI is revolutionizing innovation by speeding up creative processes and product development, reducing the time to market and allowing companies to differentiate in an often crowded field. In this blog, we’ve collected more than 300 of our favorite real-life examples of how organizations are embracing Microsoft’s proven AI capabilities to drive impact and shape today’s platform shift to AI. Today, we’ve added new stories of customers using our AI capabilities at the beginning of each section. We’ll regularly update this story with more. We hope you find an example or two that can inspire your own transformation journey. Enriching employee experiences Generative AI is truly transforming employee productivity and wellbeing. Our customers tell us that by automating repetitive, mundane tasks, employees are freed up to dive into more complex and creative work. This shift not only makes the work environment more stimulating but also boosts job satisfaction. It sparks innovation, provides actionable insights for better decision-making and supports personalized training and development opportunities, all contributing to a better work-life balance. Customers around the world have reported significant improvements in employee productivity with these AI solutions: New Stories: Acentra Health created MedScribe using Azure OpenAI Service. The solution has saved 11,000 nursing hours and nearly $800,000. It also helped each nurse process 20 to 30 letters daily, while achieving a 99% approval rate for MedScribe-generated letters. Brisbane Catholic Education provides Microsoft 365 Copilot to 12,500 educators, and uses Microsoft Copilot Studio to create a generative AI tool to help educators integrate Catholic traditions and values into the classroom. Crediclub saves 96% per month in auditing expenses and analyzes 150 meetings per hour with Azure AI, freeing up time for 800 sales advisors and 150 branch managers to interact directly with customers. eClinicalWorks developed a tool using Azure AI services and Azure AI Document Intelligence to help healthcare workers scan, sort and match thousands of faxes each year to match the faxed data with current patient files. Education Authority of Northern Ireland (EANI) introduced Microsoft 365 Copilot to reduce admin work, allowing teachers to focus on students. The Microsoft partnership ensures secure and ethical AI use, while teacher training focuses on prompt writing and effective tool adoption. Ma’aden uses Microsoft 365 Copilot to enhance productivity, saving up to 2,200 hours monthly. Tasks like drafting emails, creating documents and data analysis have become more efficient, helping Ma’aden achieve its growth goals. Marketing org mci group uses Microsoft 365 Copilot to enhance the use of AI and other technological advances to boost employee efficiency. Michelin deployed Microsoft 365 Copilot and a generative AI in-house chatbot based on Azure OpenAI Service called “Aurora” designed to help employees optimize work and team performance, boosting productivity tenfold. Raiffeisen Bank International built its own ChatGPT using Azure OpenAI Service to automate repetitive tasks like documenting intelligence and more rapidly summarize legal, regulation and banking documents. Sanabil Investments deployed Microsoft 365 Copilot to help employees reduce the time spent on manual everyday tasks that diverted focus from more strategic and valuable work. Within two months, approximately 70% of employees regularly used Copilot. Sensei rolled out Microsoft 365 to reduce the number of internal apps and better connect systems for easier collaboration, and is using Microsoft 365 Copilot to increase efficiency. Sikshana Foundation is working with Microsoft Research India to introduce an AI copilot for teachers that shortens preparation time for lessons from an hour or more to just minutes. The University of Hong Kong adopted Microsoft 365 Copilot to enhance productivity by automating administrative tasks and providing intelligent assistance, allowing faculty to focus more on teaching. Accenture and Avanade launched a Copilot business transformation practice, supported by Microsoft, and co-invested in new capabilities, solutions and training to help organizations securely and responsibly reinvent their business functions with generative and agentic AI and Copilot technologies. Access Holdings Plc adopted Microsoft 365 Copilot, integrating generative AI into daily tools and, as a result, writing code now takes two hours instead of eight, chatbots launch in 10 days instead

This was originally published on our developer newsletter, GitHub Insider, which offers tips and tricks for devs at every level. If you’re not subscribed, go do that now—you won’t regret it (we promise). If you’ve ever wondered which AI model is the best fit for your GitHub Copilot project, you’re not alone. Since each model has its own strengths, picking the right one can feel somewhat mysterious. Big disclaimer! AI moves fast, so these recommendations are subject to change. It’s mid-April 2025 right now, though things will probably be different within a week of posting. Zoom zoom zoom. With models that prioritize speed, depth, or a balance of both, it helps to know what each one brings to the table. Let’s break it down together. 👇 The TL;DR 💳 Balance between cost and performance: Go with GPT-4.1, GPT-4o, or Claude 3.5 Sonnet. 🪙 Fast, lightweight tasks: o4-mini or Claude 3.5 Sonnet are your buddies. 💎 Deep reasoning or complex debugging: Think Claude 3.7 Sonnet, o3, or GPT 4.5. 🖼️ Multimodal inputs (like images): Check out Gemini 2.0 Flash or GPT-4o. Your mileage may vary and it’s always good to try things yourself before taking someone else’s word for it, but this is how these models were designed to be used. All that being said… Let’s talk models. 🏎️ Putting coding speed first o4-mini and o3-mini: The speed demons 😈 Fast, efficient, and cost-effective, o4-mini and o3-mini are ideal for simple coding questions and quick iterations. If you’re looking for a no-frills model, use these. ✅ Use them for: Quick prototyping. Explaining code snippets. Learning new programming concepts. Generating boilerplate code. 👀 You may prefer another model: If your task spans multiple files or calls for deep reasoning, a higher‑capacity model such as GPT‑4.5 or o3 can keep more context in mind. Looking for extra expressive flair? Try GPT‑4o. ⚖️ AI models designed for balance Claude 3.5 Sonnet: The budget-friendly helper 😊 Need solid performance but watching your costs? Claude 3.5 Sonnet is like a dependable sidekick. It’s great for everyday coding tasks without burning through your monthly usage. ✅ Use it for: Writing documentation. Answering language-specific questions. Generating code snippets. 👀 You may prefer another model: For elaborate multi‑step reasoning or big‑picture planning, consider stepping up to Claude 3.7 Sonnet or GPT‑4.5. GPT-4o and GPT-4.1: The all-rounders 🌎 These are your go-to models for general tasks. Need fast responses? Check. Want to work with text *and* images? Double check. GPT-4o and GPT-4.1 are like the Swiss Army knives of AI models: flexible, dependable, and cost-efficient. ✅ Use them for: Explaining code blocks. Writing comments or docs. Generating small, reusable snippets. Multilingual prompts. 👀 You may prefer another model: Complex architectural reasoning or multi‑step debugging may land more naturally with GPT‑4.5 or Claude 3.7 Sonnet. 🧠 Models for deep thinking and big projects Claude 3.7 Sonnet: The architect 🏠 This one’s the power tool for large, complex projects. From multi-file refactoring to feature development across front end and back end, Claude 3.7 Sonnet shines when context and depth matter most. ✅ Use it for: Refactoring large codebases. Planning complex architectures. Designing algorithms. Combining high-level summaries with deep analysis. 👀 You may prefer another model: For quick iterations or straightforward tasks, Claude 3.5 Sonnet or GPT‑4o may deliver results with less overhead. Gemini 2.5 Pro: The researcher 🔎 Gemini 2.5 Pro is the powerhouse for advanced reasoning and coding. It’s built for complex tasks (think: deep debugging, algorithm design, and even scientific research). With its long-context capabilities, it can handle extensive datasets or documents with ease. ✅ Use it for: Writing full functions, classes, or multi-file logic. Debugging complex systems. Analyzing scientific data and generating insights. Processing long documents, datasets, or codebases. 👀 You may prefer another model: For cost-sensitive tasks, o4-mini or Gemini 2.0 Flash are more budget-friendly options. GPT-4.5: The thinker 💭 Got a tricky problem? Whether you’re debugging multi-step issues or crafting full-on systems architectures, GPT-4.5 thrives on nuance and complexity. ✅ Use it for: Writing detailed README files. Generating full functions or multi-file solutions. Debugging complex errors. Making architectural decisions. 👀 You may prefer another model: When you just need a quick iteration on something small—or you’re watching tokens—GPT‑4o can finish faster and cheaper. o3 and o1: The deep diver 🥽 These models are perfect for tasks that need precision and logic. Whether you’re optimizing performance-critical code or refactoring a messy codebase, o3 and o1 excel in breaking down problems step by step. ✅ Use them for: Code optimization. Debugging complex systems. Writing structured, reusable code. Summarizing logs or benchmarks. 👀 You may prefer another model: During early prototyping or lightweight tasks, a nimble model such as o4‑mini or GPT‑4o may feel snappier. 🖼️ Multimodal, or designed to handle it all Gemini 2.0 Flash: The visual thinker 🤔 Got visual inputs like UI mockups or diagrams? Gemini 2.0 Flash lets you bring images into the mix, making it a great choice for front-end prototyping or layout debugging. ✅ Use it for: Analyzing diagrams or screenshots. Debugging UI layouts. Generating code snippets. Getting design feedback. 👀 You may prefer another model: If the job demands step‑by‑step algorithmic reasoning, GPT‑4.5 or Claude 3.7 Sonnet will keep more moving parts in scope. So… which model do I choose? Here’s the rule of thumb: Match the model to the task. Practice really does make perfect, and as you work with different models, it’ll become clearer which ones work best for different tasks. The more I’ve personally used certain models, the more I’ve learned, “oh, I should switch for this particular task,” and “this one will get me there.” And because I enjoy staying employed, I would love to cheekily mention that you can (and should!) use these models with… GitHub Copilot in your favorite IDE GitHub Copilot on GitHub.com With agent mode or Copilot Edits With agent mode in Codespaces With agent mode in VS Code Good luck, go forth, and happy coding! Learn more about AI models. The post Which

GitHub Universe returns to San Francisco on October 28 and 29—bringing together the builders, dreamers, and changemakers shaping the future of software. From first-time speakers with big ideas to DevRel pros with demos to share and business leaders rethinking workflows with AI, we believe that a diverse range of voices belong on our stage. But writing a compelling conference session submission can feel like decoding a complex algorithm. What makes your idea stand out? How do you grab the content committee’s attention? And what if you’ve never done this before? Good news: we’ve cracked the code, and we’re sharing it with you. Here are four proven tips to help you put together a proposal that’s clear, compelling, and uniquely you. Apply to speak or nominate a speaker to take the stage at GitHub Universe by Friday, May 2 at 11:59 pm PT to be considered. 1. Find something you’re truly passionate about 💡 Here’s the truth: passion is magnetic. If you’re excited about your topic, it shows. It pulses through your proposal, powers your delivery onstage, and pulls in your audience—content committee included. Instead of chasing the latest trends, talk about something that lights you up. Maybe it’s a story from building an open source project in your off-hours. Maybe it’s how your team shipped something new using GitHub Copilot. Or maybe it’s the unexpected way you quickly scaled developer experience across a global org. Your unique perspective is your superpower. Content committees can sense authenticity. They’re not just looking for polished buzzwords. They’re looking for people who care deeply and can teach others something meaningful. 🎤 Pro tip: If it’s a topic you’d talk about over lunch with a teammate or geek out about on a podcast, it’s probably a great fit. 2. Write a title they can’t ignore ✍️ Think of your session title like an email subject line—it’s your chance to make a strong first impression, and it needs to do the heavy lifting for you. A strong title shouldn’t just sound good. It should clearly communicate what your talk is about and why it matters. Let’s take our title as an example: ✅ Engaging: “Cracking the Code” suggests there’s an inside strategy, and it sparks curiosity. ✅ Clear: “How to wow the acceptance committee at your next tech event” leaves no doubt about the topic. ✅ Action-oriented: It promises practical takeaways, not just theory. ✅ Balanced: It walks the line between fun and professional. Avoid vague titles (“A new approach to software”) or clickbait (“This one trick will fix your codebase”). Instead, aim for clarity with flair. Give the content committee a reason to want to learn more along with the confidence that your talk can deliver. 🎤 Pro tip: After you write your title, ask yourself—would I attend this session? Would I understand what I’m getting from it in five seconds? 3. Make it easy for the content committee to say yes ✅ The content committee is rooting for you, but you’ve got to help them out. The best submissions remove all ambiguity and make a strong case for why this session matters. Here’s how: Be specific about your audience: Who is this for? Senior engineers? OSS maintainers? Platform teams? Product leads? Spell out the takeaways: What will people learn? Tools, frameworks, fresh mindsets? Tie it to the event: Why does this belong at GitHub Universe? How does it support the event’s themes? Also, show that your content has a life beyond the stage: Can your session be turned into a blog, case study, or video? Is your abstract compelling enough to be featured in a marketing email or keynote recap? Will attendees be able to apply what they learned the next day? 🎤 Hot tip: Think beyond the talk itself. That’s pure gold for event organizers. 4. Seal the deal with your online presence 🌐 Yes, your session submission is the star, but reviewers on the content committee can also look you up. Your online presence helps us understand: Your credibility and expertise Your speaking experience (or potential!) How easy it will be to promote you as a speaker You don’t need a massive following. But you do want a strong, relevant footprint. Here are a few tips to consider: On LinkedIn: Use a headline that highlights your expertise, not just your title. Make your “About” section shine with links to talks, blogs, and projects. Add speaking experience under “Experience” or “Featured.” On GitHub: Update your profile README with your focus areas and links. Pin key repos or projects you’ve contributed to. Be active in discussions, even if most of your code is private. 🎤 Hot tip: Post about your submission journey! Sharing your process helps you engage with the community and might even inspire someone else to apply. Ready to take the stage? You’ve got the ideas. Now you’ve got the blueprint. If you’ve made it this far, we hope you feel ready—and excited—to throw your hat in the ring. Let’s recap: Lead with passion to find a topic you care deeply about. Craft a clear, compelling title that grabs attention and gives the content committee an immediate idea of your session topic and takeaways. Make your submission a no-brainer by showing how it aligns with the event and adds value. Polish your online presence—it might just tip the scale in your favor. Whether you’re a seasoned speaker or stepping into the spotlight for the first time, we can’t wait to hear from you. And if you don’t have a session idea this year, you can also nominate a speaker who deserves to take the stage. Submit a session proposal or a speaker nomination from now until Friday, May 2 at 11:59 pm PT to be considered! Apply to speak at GitHub Universe or nominate a speaker > 🎟️ Registration for the main event isn’t open yet, but if you want to be the first to know when tickets go on sale, sign up here to get notified. Let’s build the future

GitHub supports dark mode and light mode, and as developers, we can make our README images look great in both themes. Here’s a quick guide to using the <picture> element in your GitHub Markdown files to dynamically switch images based on the user’s color scheme. When developers switch to GitHub’s dark mode (or vice versa), standard images can look out of place, with bright backgrounds or clashing colors. Instead of forcing a one-size-fits-all image, you can tailor your visuals to blend seamlessly with the theme. It’s a small change, but it can make your project look much more polished. One snippet, two themes! Here’s the magic snippet you can copy into your README (or any Markdown file): <picture> <source media=”(prefers-color-scheme: dark)” srcset=”dark-mode-image.png”> <source media=”(prefers-color-scheme: light)” srcset=”light-mode-image.png”> <img alt=”Fallback image description” src=”default-image.png”> </picture> Now, we say it’s magic, but let’s take a peek behind the curtain to show how it works: The <picture> tag lets you define multiple image sources for different scenarios. The <source media=”…”> attribute matches the user’s color scheme. When media=”(prefers-color-scheme: dark)”, the browser loads the srcset image when GitHub is in dark mode. Similarly, when media=”(prefers-color-scheme: light)”, the browser loads the srcset image when GitHub is in light mode. If the browser doesn’t support the <picture> element, or the user’s system doesn’t match any defined media queries, the fallback <img> tag will be used. You can use this approach in your repo README files, documentation hosted on GitHub, and any other Markdown files rendered on GitHub.com! Demo What’s better than a demo to help you get started? Here’s what this looks like in practice: https://github.blog/wp-content/uploads/2025/04/Toggle-Dark-and-Light-Mode-on-GitHub-.mp4#t=0.001 The post How to make your images in Markdown on GitHub adjust for dark mode and light mode appeared first on The GitHub Blog. ​ Developer skills, GitHub, Github, Markdown The GitHub Blog

Recently we launched sub-issues, a feature designed to tackle complex issue management scenarios. This blog post delves into the journey of building sub-issues, what we learned along the way, how we implemented sub-issues, and the benefits of being able to use sub-issues to build itself. What are sub-issues? Sub-issues are a way to break a larger issue into smaller, more manageable tasks. With this feature, you can now create hierarchical lists within a single issue, making it easier to track progress and dependencies. By providing a clear structure, sub-issues help teams stay organized and focused on their goals. For example, I often realize that a batch of work requires multiple steps, like implementing code in different repositories. Breaking this task into discrete sub-issues makes it easier to track progress and more clearly define the work I need to do. In practice we’ve noticed this helps keep linked PRs more concise and easier to review. A brief history Issues have long been at the heart of project management on GitHub. From tracking bugs to planning feature development, issues provide a flexible and collaborative way for teams to organize their work. Over time, we’ve enriched this foundation with tools like labels, milestones, and task lists, all to make project management even more intuitive and powerful. One of the key challenges we set out to solve was how to better represent and manage hierarchical tasks within issues. As projects grow in complexity, breaking down work into smaller, actionable steps becomes essential. We want to empower users to seamlessly manage these nested relationships while maintaining the simplicity and clarity GitHub is known for. Our journey toward sub-issues began with a fundamental goal: to create a system that integrates deeply into the GitHub Issues experience, enabling users to visually and functionally organize their work without adding unnecessary complexity. Achieving this required careful design and technical innovation. Building sub-issues To build sub-issues, we began by designing a new hierarchical structure for tasks rather than modifying the existing task list functionality. We introduced the ability to nest tasks within tasks, creating a hierarchical structure. This required updates to our data models and rendering logic to support nested sub-issues. From a data modeling perspective, the sub-issues table stores the relationships between parent and child issues. For example, if Issue X is a parent of Issue Y, the sub-issues table would store this link, ensuring the hierarchical relationship is maintained. In addition, we roll up sub-issue completion information into a sub-issue list table. This allows us to performantly get progress without having to traverse through a list of sub-issues. For instance, when Issue Y is completed, the system automatically updates the progress of Issue X, eliminating the need to manually check the status of all sub-issues. We wanted a straightforward representation of sub-issues as relationships in MySQL. This approach provided several benefits, including easier support for sub-issues in environments like GitHub Enterprise Server and GitHub Enterprise Cloud with data residency. We exposed sub-issues through GraphQL endpoints, which let us build upon the new Issues experience and leverage newly crafted list-view components. This approach provided some benefits, including more efficient data fetching and enhanced flexibility in how issue data is queried and displayed. Overall, we could move faster because we reused existing components and leveraged new components that would be used in multiple features. This was all made possible by building sub-issues in the React ecosystem. We also focused on providing intuitive controls for creating, editing, and managing sub-issues. To this end, we worked closely with accessibility designers and GitHub’s shared components team that built the list view that powers sub-issues. Our goal was to make it as easy as possible for users to break down their tasks without disrupting their workflow. Using sub-issues in practice Dogfooding is a best practice at GitHub and it’s how we build GitHub! We used sub-issues extensively within our own teams throughout the company to manage complex projects and track progress. Having a discrete area to manage our issue hierarchy resulted in a simpler, more performant experience. Through this hands-on experience, we identified areas for improvement and ensured that the feature met our high standards. Our teams found that sub-Issues significantly improved their ability to manage large projects. By breaking down tasks into smaller, actionable items, they maintained better visibility and control over their work. The hierarchical structure also made it easier to identify dependencies and ensure nothing fell through the cracks. Gathering early feedback Building sub-issues was a team effort. Feedback from our beta testers was instrumental in shaping the final product and ensuring it met the needs of our community. For example, understanding how much metadata to display in the sub-issue list was crucial. We initially started with only issue titles, but eventually added the issue number and repository name, if the issue was from another repository. Building features at GitHub makes it really easy to improve our own features as we go. It was really cool to start breaking down the sub-issues work using sub-issues. This allowed us to experience the feature firsthand and identify any pain points or areas for improvement. For example, the has:sub-issues-progress and has:parent-issue filters evolved from early discussions around filtering syntax. This hands-on approach ensured that we delivered a polished and user-friendly product. These lessons have been invaluable in not only improving sub-issues, but also in shaping our approach to future feature development. By involving users early and actively using our own features, we can continue to build products that truly meet the needs of our community. These practices will be important to our development process going forward, ensuring that we deliver high-quality, user-centric solutions. Call to action Sub-issues are designed to help you break down complex tasks into manageable pieces, providing clarity and structure to your workflows. Whether you’re tracking dependencies, managing progress, or organizing cross-repository work, sub-issues offer a powerful way to stay on top of your projects. We’d love for you to try sub-issues and see how they can improve your workflow.

Whether it’s building, testing, or deploying code, automating manual processes is key to improving developer experience and achieving a successful DevOps strategy. On GitHub, you can use GitHub Actions to not only implement your CI/CD pipeline, but also automate other processes both on and off GitHub. When you are adopting GitHub Actions on GitHub Enterprise Cloud, you can choose between GitHub-hosted runners and self-hosted runners to run your workloads, and each has its pros and cons. In this post, we’ll compare GitHub-hosted runners with self-hosted runners across five areas to help you determine which type best fits your GitHub Actions adoption strategy. What are GitHub-hosted runners and self-hosted runners? GitHub-hosted runners and self-hosted runners are based on the same open-source software and both support macOS, Windows, and Linux. But they have many differences. GitHub-hosted runners are fully managed on GitHub’s infrastructure using pre-configured Windows, Linux, and macOS virtual machines. In addition to offering standard runners for typical workloads, hosted runners offer larger runners with more resources (memory, CPU, and storage), custom images, static IP ranges, and Azure Virtual Network integration for enhanced security control. Self-hosted runners operate on your own infrastructure, whether on-premises or in the cloud. You manage all aspects—configuration, security, and scaling. They also allow you to operate runners in places you couldn’t otherwise—for example, on GitHub Enterprise Server or on custom hardware. They can also be the only way to implement certain compliance requirements, especially when working with highly secured systems. Both options offer distinct advantages depending on your specific needs and resources. Let’s explore when GitHub-hosted runners may be the right choice for your projects, and when it may be better to use self-hosted runners. Fully managed or self-managed? A key distinction between these two options is where they’re hosted, as we’ve pointed out. But that choice comes with several implications. GitHub-hosted runners provide managed infrastructure with pools of on-demand virtual machines (VMs) that are automatically secured and updated. The environments are ephemeral, with the disks reimaged after each job, preventing files from previous jobs from affecting subsequent runs. The VMs are optimized for GitHub Actions, with pre-installed software and tools, including the latest versions of GitHub CLI, Docker, and common development platforms to ensure fast start times and avoid rate limits. With GitHub-hosted runners, you can jump right in and start building workflows. There’s nothing to configure or secure before you start, making them ideal when you want to get started quickly. And we all prefer to spend more time on code than infrastructure, right? Self-hosted runners offer you complete flexibility in defining your solution, but also means you are responsible for managing the infrastructure, images, caches, and security, and monitoring availability and usage against GitHub’s rate limits. This requires expertise in GitHub Actions architecture, VM and container image building, and network and infrastructure management. If your core business offering is scalable infrastructure solutions or Kubernetes, self-hosted runners may make sense. Let’s take a closer look. Scalability To remain productive, it’s important to have highly-available resources available on demand, especially for CI/CD workloads, where waiting for a job to run may mean you’re blocked from working on other tasks. In fact, a single wasted hour each week can cost a company over $4,000 a year per developer! But scaling highly available, on-demand resources is hard. Even with a well-designed cloud infrastructure, it takes time to provision new virtual machines. You need systems in multiple regions to maintain up time, with 20-25% spare capacity to scale quickly and handle unexpected system failures. GitHub-hosted runners take advantage of Microsoft’s deep data center and cloud expertise and have dedicated teams to meet our service level agreement (SLA) of 99.9% availability. And that’s without any expertise on your part. In fact, many teams consider self-hosted runners in hopes of beating this availability, but it turns out that’s not even technically possible, as all runnings depend on the same services and control plane. That said, there are conditions where self-hosted runners may work for you. Self-hosted runners may meet your needs if you need a fixed number of servers, are primarily focused on deployment to non-cloud resources, and don’t need to scale on demand. Just remember that the instances are not natively ephemeral, so you’ll need to have a strategy to keep the instances free from artifacts created by earlier runs. Self-hosted runners also lack automatic scaling capabilities; they require a scaling solution to be able to support large teams or create new instances dynamically. GitHub’s Actions Runner Controller (ARC) offers a solution, but it has limitations as it requires Kubernetes expertise and only supports Linux runners. Kubernetes relies on containers instead of VMs, which can require you to troubleshoot resource contention and scaling issues. ARC can also offer high availability by having multiple clusters. As we noted before, if your primary business is hosting and managing Kubernetes clusters, then ARC may be the right approach. ARC does not support macOS or Windows workloads, and both environments present a number of limitations. For example, on macOS, you are required to use Apple hardware, you are limited to two VMs per machine, and containerizing the Apple runtime is not supported. For Windows, virtual machines are supported, but you need a custom orchestrator for scaling the instances. While you can create Windows containers and manage them with Kubernetes, the containers have slow startup times and may not support some of the necessary development and testing tools. In short, we recommend GitHub-hosted runners for both macOS and Windows workloads. Security Security is critical for CI/CD processes, since they may require access to internal or production resources, and builds often use third-party libraries, runtimes, and tools, which can create a large attack surface if not properly secured. GitHub-hosted runners provide built-in security through a defense-in-depth, zero-trust approach. VMs provide network isolation, preventing exposure to other runners and corporate resources. In fact, access to corporate or cloud resources requires elevating privileges (we recommend OIDC). Their ephemeral nature eliminates code persistence and prevents application execution

In March, we experienced one incident that resulted in degraded performance across GitHub services. March 29 7:00 UTC (lasting 58 hours) Between March 29 7:00 UTC and March 31 17:00 UTC, GitHub experienced service degradation due to two separate, but related incidents. On March 29, users were unable to unsubscribe from GitHub marketing email subscriptions due to a service outage. Additionally, on March 31, 2025 from 7:00 UTC to 16:40 UTC users were unable to submit ebook and event registration forms on resources.github.com, also due to a service outage. The March 29 incident occurred due to expired credentials used for an internal service, preventing customers from being able to unsubscribe directly from marketing/sales topics through github.com/settings/emails UI and from performing the double opt-in step required by some countries. A similar credential expiry on March 31 resulted in users experiencing degradation accessing resources.github.com. The cause of the incident was traced to an issue in the automated alerting for monitoring upcoming credential expirations. The bug in alerting resulted in the invalid credentials being discovered after they had expired. This resulted in two incidents before we could deploy a durable fix. We mitigated it by renewing the credentials and redeploying the affected services. To improve future response times and prevent similar issues, we have enhanced our credential expiry detection, alerting, and rotation processes, and are working on improving on-call observability. Please follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the GitHub Engineering Blog. The post GitHub Availability Report: March 2025 appeared first on The GitHub Blog. ​ Company news, News & insights, GitHub Availability Report The GitHub Blog

It feels like everyone’s talking about MCP (Model Context Protocol) these days when it comes to large language models (LLMs), but hardly anyone is actually defining it. TL;DR: It’s an open standard for connecting LLMs to data and tools. Let’s dive in deeper! The context problem for LLMs LLMs often struggle when they are asked for information outside of their training data. They’ll sometimes either hallucinate and say something incorrect, or simply say, “I don’t know.” Giving them the right amount of context when you prompt them (whether it’s your codebase, your repository data, your documentation, etc.) is necessary for AI agents built on top of LLMs to be useful. Usually, you have to really refine your prompting to give LLMs that context, or use some sort of external tool. For example, GitHub Copilot has tools like @workspace to give relevant information from your codebase to your prompts. This type of “extra tooling” is cool, but can get fairly complex fairly quickly as you implement things across different APIs and services. A solution: Model Context Protocol, or MCP In November, Anthropic open sourced the Model Context Protocol as a standard for connecting LLMs and AI assistants to data and tools! MCP grew the way you sleep… slowly and then all at once. As tools and organizations have adopted the MCP standard, it has only become more and more valuable. And because MCP is model agnostic, anyone can use and create MCP integrations. As with all open standards, a rising tide lifts all boats: the more people that use it, the better it becomes. I think that MCP has “won” the hearts of so many AI developers and tools because of this openness, and also because it’s a very “AI-first” version of existing ideas. This isn’t the first time we’ve seen a protocol like this become a standard, either. Back in 2016, Microsoft released the Language Server Protocol (LSP), which provided standards for code editors to support programming languages. Fast forward to today: because of LSP, programming language support across editors is better than ever, to the point where developers don’t even need to think about it anymore! MCP takes a lot of its inspiration from LSP, and could be absolutely transformative for AI tooling. It allows for everyone, from the largest tech giants to the smallest indie developer shops, to enable robust AI solutions in any AI client with minimal setup. That’s why this is a huge deal! An open standard that is backed more and more by the tech community means better tools, better developer experiences, and better user experiences for everyone. GitHub and MCP We’re not just talking about MCP: we’re contributing, too! We’re SO excited to have recently released our new open source, official, local GitHub MCP Server! It provides seamless integration with GitHub APIs, allowing for advanced automation and integration capabilities for developers to build with! You can chat more with us about it in the GitHub Community or you can check out the official announcement. How do I contribute and learn more? Hoorah, I thought you’d never ask! Here’s some resources to get you on your way: MCP documentation Repository of reference implementations for MCP MCP specification for protocol requirements More documentation on LSP Also, if you don’t mind the shameless plug, you can also use it with agent mode now. Go forth and code! The post What the heck is MCP and why is everyone talking about it? appeared first on The GitHub Blog. ​ AI & ML, LLMs, Open Source, GitHub Copilot, LLM, Model Context Protocol, open source, Open Standards The GitHub Blog

Let’s be honest—most security tools can be pretty painful to use. These tools usually aren’t designed with you, the developer, in mind—even if it’s you, not the security team, who is often responsible for remediating issues. The worst part? You frequently need to switch back and forth between your tool and your dev environment, or add a clunky integration. And oftentimes the alerts aren’t very actionable. You may need to spend time researching on your own. Or worse, false positives can pull you away from building the next thing. Alert fatigue creeps in, and you find yourself paying less and less attention as the vulnerabilities stack up. We’re trying to make this better at GitHub by building security into your workflows so you can commit better code. From Secret Protection to Code Security to Dependabot and Copilot Autofix, we’re working to go beyond detection to help you prioritize and remediate problems—with a little help from AI. We’re going to show you how to write more secure code on GitHub, all in less than 10 minutes. At commit and before the pull request: Secret Protection You’ve done some work and you’re ready to commit your code to GitHub. But there’s a problem: You’ve accidentally left an API key in your code. Even if you’ve never left a secret in your code before, there’s a good chance you will someday. Leaked secrets are one of the most common, and most damaging, forms of software vulnerability. In 2024, developers across GitHub simplified the process by using Secret Protection, detecting more than 39 million secret leaks. Let’s start with some context. Traditionally, it could take months to uncover the forgotten API key because security reviews would take place only after a new feature is finished. It might not even be discovered until someone exploited it in the wild. In that case, you’d have to return to the code, long after you’d moved on to working on other features, and rewrite it. But GitHub Secret Protection, formerly known as Secret Scanning, can catch many types of secrets before they can cause you real pain. Secret Protection runs when you push code to your repository and will warn you if it finds something suspicious. You will know right away that something is wrong and can fix it while the code is fresh in your mind. Push protection—which blocks contributors from pushing secrets to a repository and generates an alert whenever a contributor bypasses the block—shows you exactly where the secret is so you can fix it before there’s any chance of it falling into the wrong hands. If the secret is part of a test environment or the alert is a false positive, you can easily bypass the alert, so it will never slow you down unnecessarily. What you don’t have to do is jump to another application or three to read about a vulnerability alert or issue assignment. Want to get started? Check out our documentation on Secret Protection on GitHub > After commit: Dependabot OK, so now you’ve committed some code. Chances are it contains one or more open source dependencies. Open source is crucial for your day-to-day development work, but a single vulnerability in a transient dependency—that is to say, your dependencies’ dependencies—could put your organization at risk (which isn’t something you want coming up in a performance review). Dependabot, our free tool for automated software supply chain security, helps surface vulnerabilities in your dependencies in code you’ve committed. And once again, it finds problems right away—not when the security team has a chance to review a completed feature. If a fix already exists, Dependabot will create a pull request for you, enabling you to fix issues without interrupting your workflow. Dependabot now features data to help you prioritize fixes. Specifically, alerts now include Exploit Prediction Scoring System (EPSS) data from the global Forum of Incident Response and Security Teams to help you prioritize alerts based on exploit likelihood. Only 10% of vulnerability alerts have an EPSS score above 0.95%, so you can focus on fixing this smaller subset of more urgent vulnerabilities. It can really make your backlog easier to manage and keep you from spending time on low-risk issues. Want to get started? Check out our documentation on Dependabot > At the pull request: Code Security You’ve committed some code, you’re confident you haven’t leaked any secrets, and you’re not relying on dependencies with known vulnerabilities. So, naturally, you create a pull request. Traditionally, you might be expected to run some linters and security scanning tools yourself, probably switching between a number of disparate tools. Thanks to our automation platform GitHub Actions, all of this happens as soon as you file your pull request. You can run a variety of different security tools using Actions or our security scanning service GitHub Code Security (formerly known as Code Scanning). Our semantic static analysis engine CodeQL transforms your code into a database that you can query to surface known vulnerabilities and their unknown variations, potentially unsafe coding practices, and other code quality issues. You can write your own CodeQL queries, but GitHub provides thousands of queries that cover the most critical types of vulnerabilities. These queries have been selected for their high level of accuracy, ensuring a low false positive rate for the user. But we don’t just flag problems. We now recommend solutions for 90% of alert types in JavaScript, Typescript, Java, and Python thanks to GitHub Copilot Autofix, a new feature available for free on public repositories or as part of GitHub Code Security for private repositories. Let’s say you’ve got a pesky SQL injection vulnerability (it happens all the time). Copilot Autofix will create a pull request for you with a suggested fix, so you can quickly patch a vulnerability. You no longer need to be a security expert to find a fix. We’ve found that teams using Autofix remediate vulnerabilities up to 60% faster, significantly reducing Mean Time to Remediation (MTTR). This is what we mean when we

Exactly twenty years ago, on April 7, 2005, Linus Torvalds made the very first commit to a new version control system called Git. Torvalds famously wrote Git in just 10 days after Linux kernel developers lost access to their proprietary tool, BitKeeper, due to licensing disagreements. In fact, in that first commit, he’d written enough of Git to use Git to make the commit! Git’s unconventional and decentralized design—nowadays ubiquitous and seemingly obvious—was revolutionary at the time, and reshaped how software teams collaborate and develop. (To wit, GitHub!) To celebrate two decades of Git, we sat down with Linus himself to revisit those early days, explore the key design decisions behind Git’s lasting success, and discuss how it forever changed software development. Check out the transcript of our interview below, and check back later this week for the full video of our interview. Want to watch a sneak peek of our video interview with Linus? 👇 https://github.blog/wp-content/uploads/2025/04/LINUS-TORVALDS-INTERVIEW-SOCIAL-CLIP_BLOG.mp4#t=0.001 The following transcript has been lightly edited for clarity. Taylor Blau: It’s been 20 years, almost to the hour, since Git was self-hosted enough to write its initial commit. Did you expect to be sitting here 20 years later, still using it and talking about it? Linus Torvalds: Still using it, yes. Maybe not talking about it. I mean, that has been one of the big surprises—basically how much it took over the whole SCM world. I saw it as a solution to my problems, and I obviously thought it was superior. Even literally 20 years ago to the day, I thought that first version, which was pretty raw—to be honest, even that version was superior to CVS. But at the same time, I’d seen CVS just hold on to the market—I mean, SVN came around, but it’s just CVS in another guise, right?—for many, many decades. So I was like, okay, this market is very sticky. I can’t use CVS because I hate it with a passion, so I’ll do my own thing. I couldn’t use BitKeeper, obviously, anymore. So I was like, okay, I’ll do something that works for me, and I won’t care about anybody else. And really that showed in the first few months and years—people were complaining that it was kind of hard to use, not intuitive enough. And then something happened, like there was a switch that was thrown. “I’ll do something that works for me, and I won’t care about anybody else.” Well, you mentioned BitKeeper. Maybe we can talk about that. Sure. Pretty famously, you wrote the initial version of Git in around 10 or so days as a replacement for the kernel. Yes and no. It was actually fewer than—well, it was about 10 days until I could use it for the kernel, yes. But to be fair, the whole process started like December or November the year before, so 2004. What happened was BitKeeper had always worked fairly well for me. It wasn’t perfect, but it was light years ahead of anything else I’ve tried. But BitKeeper in the kernel community was always very, like, not entirely welcomed by the community because it was commercial. It was free for open source use because Larry McVoy, who I knew, really liked open source. I mean, at the same time, he was making a business around it and he wanted to sell BitKeeper to big companies. [It] not being open source and being used for one of the biggest open source projects around was kind of a sticking point for a lot of people. And it was for me, too. Interested in participating more in the Git community? Join Git Merge 2025 at GitHub HQ in San Francisco on September 29 and 30. I mean, to some degree I really wanted to use open source, but at the same time I’m very pragmatic and there was nothing open source that was even remotely good enough. So I was kind of hoping that something would come up that would be better. But what did come up was that Tridge in Australia basically reverse engineered BitKeeper, which wasn’t that hard because BitKeeper internally was basically a good wrapper around SCCS, which goes back to the 60s. SCCS is almost worse than CVS. But that was explicitly against the license rules for BitKeeper. BitKeeper was like, you can use this for open source, but you can’t reverse engineer it. And you can’t try to clone BitKeeper. And that made for huge issues. And this was all in private, so I was talking to Larry and I was emailing with Tridge and we were trying to come up with a solution, but Tridge and Larry were really on completely opposite ends of the spectrum and there was no solution coming up. So by the time I started writing Git, I had actually been thinking about the issue for four months and thinking about what worked for me and thinking about “How do I do something that does even better than BitKeeper does but doesn’t do it the way BitKeeper does it?” I did not want to be in the situation where Larry would say, “Hey, you did the one thing you were not supposed to do.” “…how do I do something that does even better than BitKeeper does, but doesn’t do it the way BitKeeper does it.” So yes, the writing part was maybe 10 days until I started using Git for the kernel, but there was a lot of mental going over what the ideas should be. I want to talk about maybe both of those things. We can start with that 10-day period. So as I understand it, you had taken that period as a time away from the kernel and had mostly focused on Git in isolation. What was that transition like for you to just be working on Git and not thinking about the kernel? Well, since it was only two weeks, it ended up being that way. It wasn’t actually a huge deal.