Creates a new Git repository on your GitHub/ GitLab account: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing.
Automatically provisions resources the app needs: If your repository requires Cloudflare primitives like a Workers KV namespace, a D1 database, or an R2 bucket, Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment.
Configures Workers Builds (CI/CD): Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of Workers Builds.
There is nothing more frustrating than struggling to kick the tires on a new project because you don’t know where to start. Over the past couple of months, we’ve launched some improvements to getting started on Workers, including a gallery of Git-connected templates that help you kickstart your development journey.
But we think there’s another part of the story. Everyday, we see new Workers applications being built and open-sourced by developers in the community, ranging from starter projects to mission critical applications. These projects are designed to be shared, deployed, customized, and contributed to. But first and foremost, they must be simple to deploy.
If you’ve open-sourced a new Workers application before, you may have listed in your README the following in order to get others going with your repository:
“Clone this repo”
“Install these packages”
“Install Wrangler”
“Create this database”
“Paste the database ID back into your config file”
“Run this command to deploy”
“Push to a new Git repo”
“Set up CI”
And the list goes on the more complicated your application gets, deterring other developers and making your project feel intimidating to deploy. Now, your project can be up and running in one shot — which means more traction, more feedback, and more contributions.
We’re not just talking about building and sharing small starter apps but also complex pieces of software. If you’ve ever self-hosted your own instance of an application on a traditional cloud provider before, you’re likely familiar with the pain of tedious setup, operational overhead, or hidden costs of your infrastructure.
Self-hosting with traditional cloud provider
Self-hosting with Cloudflare
Setup a VPC
Install tools and dependencies
Set up and provision storage
Manually configure CI/CD pipeline to automate deployments
Scramble to manually secure your environment if a runtime vulnerability is discovered
Configure autoscaling policies and manage idle servers
✅Serverless
✅Highly-available global network
✅Automatic provisioning of datastores like D1 databases and R2 buckets
✅Built-in CI/CD workflow configured out of the box
✅Automatic runtime updates to keep your environment secure
✅Scale automatically and only pay for what you use.
By making your open-source repository accessible with a Deploy to Cloudflare button, you can allow other developers to deploy their own instance of your app without requiring deep infrastructure expertise.
We’re inviting all Workers developers looking to open-source their project to add Deploy to Cloudflare buttons to their projects and help others get up and running faster. We’ve already started working with open-source app developers! Here are a few great examples to explore:
Fiberplane helps developers build, test and explore Hono APIs and AI Agents in an embeddable playground. This Developer Week, Fiberplane released a set of sample Worker applications built on the ‘HONC' stack — Hono, Drizzle ORM, D1 Database, and Cloudflare Workers — that you can use as the foundation for your own projects. With an easy one-click Deploy to Cloudflare, each application comes preconfigured with the open source Fiberplane API Playground, making it easy to generate OpenAPI docs, test your handlers, and explore your API, all within one embedded interface.
You can now build and deploy remote Model Context Protocol (MCP) servers on Cloudflare Workers! MCP servers provide a standardized way for AI agents to interact with services directly, enabling them to complete actions on users' behalf. Cloudflare's remote MCP server implementation supports authentication, allowing users to login to their service from the agent to give it scoped permissions. This gives users the ability to interact with services without navigating dashboards or learning APIs — they simply tell their AI agent what they want to accomplish.
AI agents are intelligent systems capable of autonomously executing tasks by making real-time decisions about which tools to use and how to structure their workflows. Unlike traditional automation (which follows rigid, predefined steps), agents dynamically adapt their strategies based on context and evolving inputs. This template serves as a starting point for building AI-driven chat agents on Cloudflare's Agent platform. Powered by Cloudflare’s Agents SDK, it provides a solid foundation for creating interactive AI chat experiences with a modern UI and tool integrations capabilities.
Be sure to make your Git repository public and add the following snippet including your Git repository URL.
\n
[](https://deploy.workers.cloudflare.com/?url=<YOUR_GIT_REPO_URL>)
\n
When another developer clicks your Deploy to Cloudflare button, Cloudflare will parse the Wrangler configuration file, provision any resources detected, and create a new repo on their account that’s updated with information about newly created resources. For example:
\n
{\n "compatibility_date": "2024-04-03",\n\n "d1_databases": [\n {\n "binding": "MY_D1_DATABASE",\n\n\t//will be updated with newly created database ID\n "database_id": "1234567890abcdef1234567890abcdef"\n }\n ]\n}
\n
Check out our documentation for more information on how to set up a deploy button for your application and best practices to ensure a successful deployment for other developers.
For new Cloudflare developers, keep an eye out for “Deploy to Cloudflare” buttons across the web, or simply paste the URL of any public GitHub or GitLab repository containing a Workers application into the Cloudflare dashboard to get started.
\n \n \n
During Developer Week, tune in to our blog as we unveil new features and announcements — many including Deploy to Cloudflare buttons — so you can jump right in and start building!
"],"published_at":[0,"2025-04-08T14:00+01:00"],"updated_at":[0,"2025-04-08T13:00:02.729Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/38pbnujhmJ8qz7MTyQ5B6V/3ceafd1241de33f3a61bc2900be4c5b9/image1.png"],"tags":[1,[[0,{"id":[0,"2xCnBweKwOI3VXdYsGVbMe"],"name":[0,"Developer Week"],"slug":[0,"developer-week"]}],[0,{"id":[0,"6hbkItfupogJP3aRDAq6v8"],"name":[0,"Cloudflare Workers"],"slug":[0,"workers"]}],[0,{"id":[0,"4HIPcb68qM0e26fIxyfzwQ"],"name":[0,"Developers"],"slug":[0,"developers"]}],[0,{"id":[0,"3txfsA7N73yBL9g3VPBLL0"],"name":[0,"Open Source"],"slug":[0,"open-source"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Nevi Shah"],"slug":[0,"nevi"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2WVp9J8BoRJaBMR7crkqWH/f7814ed0df05b50babb47c6ff5b936e5/nevi.png"],"location":[0,null],"website":[0,null],"twitter":[0,"@nevikashah"],"facebook":[0,null]}]]],"meta_description":[0,"You can now add a Deploy to Cloudflare button to your repository’s README when building a Workers application, making it simple for other developers to set up and deploy your project! "],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/deploy-workers-applications-in-seconds"],"metadata":[0,{"title":[0,"Skip the setup: deploy a Workers application in seconds"],"description":[0,"You can now add a Deploy to Cloudflare button to your repository’s README when building a Workers application, making it simple for other developers to set up and deploy your project! "],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5apJrvxfcNveJr5PhvhOA1/bdc0287863c9baf2086ab9848aba1de3/Skip_the_setup-_deploy_a_Workers_application_in_seconds-OG.png"]}]}],[0,{"id":[0,"01zA7RtUKkhrUeINJ9AIS3"],"title":[0,"Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH"],"slug":[0,"open-sourcing-openpubkey-ssh-opkssh-integrating-single-sign-on-with-ssh"],"excerpt":[0,"OPKSSH (OpenPubkey SSH) is now open-sourced as part of the OpenPubkey project."],"featured":[0,false],"html":[0,"
OPKSSH makes it easy to SSH with single sign-on technologies like OpenID Connect, thereby removing the need to manually manage and configure SSH keys. It does this without adding a trusted party other than your identity provider (IdP).
A cornerstone of modern access control is single sign-on (SSO), where a user authenticates to an identity provider (IdP), and in response the IdP issues the user a token. The user can present this token to prove their identity, such as “Google says I am Alice”. SSO is the rare security technology that both increases convenience — users only need to sign in once to get access to many different systems — and increases security.
OpenID Connect (OIDC) is the main protocol used for SSO. As shown below, in OIDC the IdP, called an OpenID Provider (OP), issues the user an ID Token which contains identity claims about the user, such as “email is alice@example.com”. These claims are digitally signed by the OP, so anyone who receives the ID Token can check that it really was issued by the OP.
Unfortunately, while ID Tokens do include identity claims like name, organization, and email address, they do not include the user’s public key. This prevents them from being used to directly secure protocols like SSH or End-to-End Encrypted messaging.
Note that throughout this post we use the term OpenID Provider (OP) rather than IdP, as OP specifies the exact type of IdP we are using, i.e., an OpenID IdP. We use Google as an example OP, but OpenID Connect works with Google, Azure, Okta, etc.
\n \n \n
Shows a user Alice signing in to Google using OpenID Connect and receiving an ID Token
OpenPubkey, shown below, adds public keys to ID Tokens. This enables ID Tokens to be used like certificates, e.g. “Google says alice@example.com is using public key 0x123.” We call an ID token that contains a public key a PK Token. The beauty of OpenPubkey is that, unlike other approaches, OpenPubkey does not require any changes to existing SSO protocols and supports any OpenID Connect compliant OP.
\n \n \n
Shows a user Alice signing in to Google using OpenID Connect/OpenPubkey and then producing a PK Token\nWhile OpenPubkey enables ID Tokens to be used as certificates, OPKSSH extends this functionality so that these ID Tokens can be used as SSH keys in the SSH protocol. This adds SSO authentication to SSH without requiring changes to the SSH protocol.
OPKSSH frees users and administrators from the need to manage long-lived SSH keys, making SSH more secure and more convenient.
“In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.” \n- Challenges in Managing SSH Keys – and a Call for Solutions by Tatu Ylonen (Inventor of SSH)
In SSH, users generate a long-lived SSH public key and SSH private key. To enable a user to access a server, the user or the administrator of that server configures that server to trust that user’s public key. Users must protect the file containing their SSH private key. If the user loses this file, they are locked out. If they copy their SSH private key to multiple computers or back up the key, they increase the risk that the key will be compromised. When a private key is compromised or a user no longer needs access, the user or administrator must remove that public key from any servers it currently trusts. All of these problems create headaches for users and administrators.
OPKSSH overcomes these issues:
Improved security: OPKSSH replaces long-lived SSH keys with ephemeral SSH keys that are created on-demand by OPKSSH and expire when they are no longer needed. This reduces the risk a private key is compromised, and limits the time period where an attacker can use a compromised private key. By default, these OPKSSH public keys expire every 24 hours, but the expiration policy can be set in a configuration file.
Improved usability: Creating an SSH key is as easy as signing in to an OP. This means that a user can SSH from any computer with opkssh installed, even if they haven’t copied their SSH private key to that computer.
To generate their SSH key, the user simply runs opkssh login, and they can use ssh as they typically do.
Improved visibility: OPKSSH moves SSH from authorization by public key to authorization by identity. If Alice wants to give Bob access to a server, she doesn’t need to ask for his public key, she can just add Bob’s email address bob@example.com to the OPKSSH authorized users file, and he can sign in. This makes tracking who has access much easier, since administrators can see the email addresses of the authorized users.
OPKSSH does not require any code changes to the SSH server or client. The only change needed to SSH on the SSH server is to add two lines to the SSH config file. For convenience, we provide an installation script that does this automatically, as seen in the video below.
Shows a user Alice SSHing into a server with her PK Token inside her SSH public key. The server then verifies her SSH public key using the OpenPubkey verifier.
Let’s look at an example of Alice (alice@example.com) using OPKSSH to SSH into a server:
Alice runs opkssh login. This command automatically generates an ephemeral public key and private key for Alice. Then it runs the OpenPubkey protocol by opening a browser window and having Alice log in through their SSO provider, e.g., Google.
If Alice SSOs successfully, OPKSSH will now have a PK Token that commits to Alice’s ephemeral public key and Alice’s identity. Essentially, this PK Token says “alice@example.com authenticated her identity and her public key is 0x123…”.
OPKSSH then saves to Alice’s .ssh directory:
an SSH public key file that contains Alice’s PK Token
and an SSH private key set to Alice’s ephemeral private key.
When Alice attempts to SSH into a server, the SSH client will find the SSH public key file containing the PK Token in Alice’s .ssh directory, and it will send it to the SSH server to authenticate.
The SSH server forwards the received SSH public key to the OpenPubkey verifier installed on the SSH server. This is because the SSH server has been configured to use the OpenPubkey verifier via the AuthorizedKeysCommand.
The OpenPubkey verifier receives the SSH public key file and extracts the PK Token from it. It then verifies that the PK Token is unexpired, valid, signed by the OP and that the public key in the PK Token matches the public key field in the SSH public key file. Finally, it extracts the email address from the PK Token and checks if alice@example.com is allowed to SSH into this server.
Consider the problems we face in getting OpenPubkey to work with SSH without requiring any changes to the SSH protocol or software:
How do we get the PK Token from the user’s machine to the SSH server inside the SSH protocol?\nWe use the fact that SSH public keys can be SSH certificates, and that SSH certificates have an extension field that allows arbitrary data to be included in the certificate. Thus, we package the PK Token into an SSH certificate extension so that the PK Token will be transmitted inside the SSH public key as a normal part of the SSH protocol. This enables us to send the PK Token to the SSH server as additional data in the SSH certificate, and allows OPKSSH to work without any changes to the SSH client.
How do we check that the PK Token is valid once it arrives at the SSH server?\nSSH servers support a configuration parameter called the AuthorizedKeysCommandthat allows us to use a custom program to determine if an SSH public key is authorized or not. Thus, we change the SSH server’s config file to use the OpenPubkey verifier instead of the SSH verifier by making the following two line change to sshd_config:
The OpenPubkey verifier will check that the PK Token is unexpired, valid and signed by the OP. It checks the user’s email address in the PK Token to determine if the user is authorized to access the server.
How do we ensure that the public key in the PK Token is actually the public key that secures the SSH session?\nThe OpenPubkey verifier also checks that the public key in the public key field in the SSH public key matches the user’s public key inside the PK Token. This works because the public key field in the SSH public key is the actual public key that secures the SSH session.
We have open sourced OPKSSH under the Apache 2.0 license, and released it as openpubkey/opkssh on GitHub. While the OpenPubkey project has had code for using SSH with OpenPubkey since the early days of the project, this code was intended as a prototype and was missing many important features. With OPKSSH, SSH support in OpenPubkey is no longer a prototype and is now a complete feature. Cloudflare is not endorsing OPKSSH, but simply donating code to OPKSSH.
OPKSSH provides the following improvements to OpenPubkey:
There are a number of ways to get involved in OpenPubkey or OPKSSH. The project is organized through the OPKSSH GitHub. We are building an open and friendly community and welcome pull requests from anyone. If you are interested in contributing, see our contribution guide.
We run a community meeting every month which is open to everyone, and you can also find us over on the OpenSSF Slack in the #openpubkey channel.
"],"published_at":[0,"2025-03-25T13:00+00:00"],"updated_at":[0,"2025-03-26T14:28:34.974Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1SXiWOhmwfDs86m6u84i8l/7b6b0874f6f2f91964b87383349c7785/image2.png"],"tags":[1,[[0,{"id":[0,"3txfsA7N73yBL9g3VPBLL0"],"name":[0,"Open Source"],"slug":[0,"open-source"]}],[0,{"id":[0,"64Z8wlRoBi6qbWfgdpgCJl"],"name":[0,"SSH"],"slug":[0,"ssh"]}],[0,{"id":[0,"6qgGalxjft44m5oDkd3i1p"],"name":[0,"Single Sign On (SSO)"],"slug":[0,"sso"]}],[0,{"id":[0,"1QsJUMpv0QBSLiVZLLQJ3V"],"name":[0,"Cryptography"],"slug":[0,"cryptography"]}],[0,{"id":[0,"7FzaH9AEvtFLQN298eEwwU"],"name":[0,"Authentication"],"slug":[0,"authentication"]}],[0,{"id":[0,"1x7tpPmKIUCt19EDgM1Tsl"],"name":[0,"Research"],"slug":[0,"research"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Ethan Heilman"],"slug":[0,"ethan-heilman"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4O71DnT2dvNJsTmWv6PnQI/42a821c809de522be30aa15ea8477fc0/Ethan_Heilman.webp"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}]]],"meta_description":[0,"OPKSSH (OpenPubkey SSH) is now open-sourced as part of the OpenPubkey project. This enables users and organizations to configure SSH to work with single sign-on technologies like OpenID Connect, removing the need to manually manage & configure SSH keys without adding a trusted party other than your IdP."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/open-sourcing-openpubkey-ssh-opkssh-integrating-single-sign-on-with-ssh"],"metadata":[0,{"title":[0,"Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH"],"description":[0,"OPKSSH (OpenPubkey SSH) is now open-sourced as part of the OpenPubkey project. This enables users and organizations to configure SSH to work with single sign-on technologies like OpenID Connect, removing the need to manually manage & configure SSH keys without adding a trusted party other than your IdP."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3YFOkinUKPO3rl18jJKJnb/6fc2b6a7b4d51985155e34b6bd1f56e2/Open-sourcing_OpenPubkey_SSH__OPKSSH_-_integrating_single_sign-on_with_SSH-OG.png"]}]}],[0,{"id":[0,"6HAo0CAvmODAhYHnIF5Hbr"],"title":[0,"Open source all the way down: Upgrading our developer documentation"],"slug":[0,"open-source-all-the-way-down-upgrading-our-developer-documentation"],"excerpt":[0,"At Cloudflare, we treat developer content like an open source product. This collaborative approach enables global contributions to enhance quality and relevance for a wide range of users. This year,"],"featured":[0,false],"html":[0,"
At Cloudflare, we treat developer content like a product, where we take the user and their feedback into consideration. We are constantly iterating, testing, analyzing, and refining content. Inspired by agile practices, treating developer content like an open source product means we approach our documentation the same way an open source software project is created and maintained. Open source documentation empowers the developer community because it allows anyone, anywhere, to contribute content. By making both the content and the framework of the documentation site publicly accessible, we provide developers with the opportunity to not only improve the material itself but also understand and engage with the processes that govern how the documentation is built, approved, and maintained. This transparency fosters collaboration, learning, and innovation, enabling developers to contribute their expertise and learn from others in a shared, open environment. We also provide feedback to other open source products and plugins, giving back to the same community that supports us.
\n
\n
Building the best open source documentation experience
Great documentation empowers users to be successful with a new product as quickly as possible, showing them how to use the product and describing its benefits. Relevant, timely, and accurate content can save frustration, time, and money. Open source documentation adds a few more benefits, including building inclusive and supportive communities that help reduce the learning curve. We love being open source!
While the Cloudflare content team has scaled to deliver documentation alongside product launches, the open source documentation site itself was not scaling well. developers.cloudflare.com had outgrown the workflow for contributors, plus we were missing out on all the neat stuff created by developers in the community.
Just like a software product evaluation, we reviewed our business needs. We asked ourselves if remaining open source was appropriate? Were there other tools we wanted to use? What benefits did we want to see in a year or in five years? Our biggest limitations in addition to the contributor workflow challenges seemed to be around scalability and high maintenance costs for user experience improvements.
After compiling our wishlist of new features to implement, we reaffirmed our commitment to open source. We valued the benefit of open source in both the content and the underlying framework of our documentation site. This commitment goes beyond technical considerations, because it's a fundamental aspect of our relationship with our community and our philosophy of transparency and collaboration. While the choice of an open source framework to build the site on might not be visible to many visitors, we recognized its significance for our community of developers and contributors. Our decision-making process was heavily influenced by two primary factors: first, whether the update would enhance the collaborative ecosystem, and second, how it would improve the overall documentation experience. This focus reflects that our open source principles, applied to both content and infrastructure, are essential for fostering innovation, ensuring quality through peer review, and building a more engaged and empowered user community.
\n
\n
Cloudflare developer documentation: A collaborative open source approach
Cloudflare’s developer documentation is open source on GitHub, with content supporting all of Cloudflare’s products. The underlying documentation engine has gone through a few iterations, with the first version of the site released in 2020. That first version provided dev-friendly features such as dark mode and proper code syntax.
In 2021, we introduced a new custom documentation engine, bringing significant improvements to the Cloudflare content experience. The benefits of the Gatsby to Hugo migration included:
Faster development flow: The development flow replicated production behavior, increasing iteration speed and confidence. Preview links via Cloudflare Pages were also introduced, so the content team and stakeholders could quickly review what content would look like in production.
Custom components: Introduced features like resources-by-selector which let us reference content throughout the repository and gave us the flexibility to expand checks and automations.
Structured changelog management: Implementation of structured YAML changelog entries which facilitated sharing with various platforms like RSS feeds, Developer Discord, and within the docs themselves.
Improved performance: Significant page load time improvements with the migration to HTML-first and almost instantaneous local builds.
These features were non-negotiable as part of our evaluation of whether to migrate. We knew that any update to the site had to maintain the functionality we’d established as core parts of the new experience.
\n
\n
2024 update: Say “hello, world!” to our new developer documentation, powered by Astro
After careful evaluation, we chose to migrate from Hugo to the Astro (and by extension, JavaScript) ecosystem. Astro fulfilled many items on our wishlist including:
Enhanced content organization: Improved tagging and better cross-referencing of related pages.
Extensibility: Support for user plugins like starlight-image-zoom for lightbox functionality.
Development experience: Type-checking at build time with astro check, along with syntax highlighting, Intellisense, diagnostic messages, and plugins for ESLint, Stylelint, and Prettier.
JavaScript/TypeScript support: Aligned the docs site framework with the preferred languages of many contributors, facilitating easier contribution.
CSS management: Introduction of Tailwind and scoped styles.
Starlight, Astro’s documentation theme, was a key factor in the decision. Its powerful component overrides and plugins system allowed us to leverage built-in components and base styling.
Content needed to be migrated quickly. With dozens of pull requests opened and merged each day, entering a code freeze for a week simply wasn’t feasible. This is where the nature of abstract syntax trees (ASTs) came into play, only parsing the structure of a Markdown document rather than details like whitespace or indentation that would make a regular expression approach tricky.
With Hugo in 2021, we configured code block functionality like titles or line highlights with front matter inside the code block.
When we migrated from Gatsby to Hugo in 2021, the pull request included 4,850 files and the migration took close to three weeks from planning to implementation. This time around, the migration was nearly twice as large, with 8,060 files changed. Our planning and migration took six weeks in total:
10 days: Evaluate platforms, vendors, and features
14 days: Migrate the components required by the documentation site
The migration resulted in removing a net -19,624 lines of code from our maintenance burden.
\n \n \n
While the number of files had grown substantially since our last major migration, our strategy was very similar to the 2021 migration. We used Markdown AST and astray, a utility to walk ASTs, created specifically for the previous migration!
A website migration like our move to Astro/Starlight is a complex process that requires time to plan, review, and coordinate, and our preparation paid off! Including our Cloudflare Community MVPs as part of the planning and review period proved incredibly helpful. They provided great guidance and feedback as we planned for the migration. We only needed one day of code freeze, and there were no rollbacks or major incidents. Visitors to the site never experienced downtime, and overall the migration was a major success.
During testing, we ran into several use cases that warranted using experimental Astro APIs. These APIs were always well documented, thanks to fantastic open source content from the Astro community. We were able to implement them quickly without impacting our release timeline.
We also ran into an edge case with build time performance due to the number of pages on our site (4000+). The Astro team was quick to triage the problem and begin investigation for a permanent fix. Their fast, helpful fixes made us truly grateful for the support from the Astro Discord server. A big thank you to the Astro/Starlight community!
Migrating developers.cloudflare.com to Astro/Starlight is just one example of the ways we prioritize world-class documentation and user experiences at Cloudflare. Our deep investment in documentation makes this a great place to work for technical writers, UX strategists, and many other content creators. Since adopting a content like a product strategy in 2021, we have evolved to better serve the open source community by focusing on inclusivity and transparency, which ultimately leads to happier Cloudflare users.
We invite everyone to connect with us and explore these exciting new updates. Feel free to reach out if you’d like to speak with someone on the content team or share feedback about our documentation. You can share your thoughts or submit a pull request directly on the cloudflare-docs repository in GitHub.
"],"published_at":[0,"2025-01-08T14:00+00:00"],"updated_at":[0,"2025-01-08T14:00:03.578Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/39T3oFp8K80C21v3tOQxsc/2006154cf15184a17e61165cbec58b3e/BLOG-2600_1.png"],"tags":[1,[[0,{"id":[0,"7nUqeGThZ2m4zUG1xv6ffg"],"name":[0,"Technical Writing"],"slug":[0,"technical-writing"]}],[0,{"id":[0,"3txfsA7N73yBL9g3VPBLL0"],"name":[0,"Open Source"],"slug":[0,"open-source"]}],[0,{"id":[0,"17eVIVTZv365SSCxzaDL9o"],"name":[0,"Developer Documentation"],"slug":[0,"developer-documentation"]}],[0,{"id":[0,"4HIPcb68qM0e26fIxyfzwQ"],"name":[0,"Developers"],"slug":[0,"developers"]}],[0,{"id":[0,"3JAY3z7p7An94s6ScuSQPf"],"name":[0,"Developer Platform"],"slug":[0,"developer-platform"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Kim Jeske"],"slug":[0,"kim"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1SDxpGoF91lM10f0XhL8O4/a908a8f914260396b646107c396b1de6/kim.png"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}],[0,{"name":[0,"Kian Newman-Hazel"],"slug":[0,"kian-newman-hazel"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/48ksPIMXauCn5H9RdlYj3H/9f672f14dcdb2555f5a32aa73efb504c/IMG_8432.jpg"],"location":[0,"United Kingdom"],"website":[0],"twitter":[0],"facebook":[0]}],[0,{"name":[0,"Kody Jackson"],"slug":[0,"kody"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1uXVtuGTFZLmrGCd37Yog8/e54bed777ce72671e6dab85692a8ecd7/kody.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}]]],"meta_description":[0,"At Cloudflare, we treat developer content like an open source product. This collaborative approach enables global contributions to enhance quality and relevance for a wide range of users. This year, we scaled our documentation site to better meet the needs of users by migrating to the Astro ecosystem."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/open-source-all-the-way-down-upgrading-our-developer-documentation"],"metadata":[0,{"title":[0,"Open source all the way down: Upgrading our developer documentation"],"description":[0,"At Cloudflare, we treat developer content like an open source product. This collaborative approach enables global contributions to enhance quality and relevance for a wide range of users. This year, we scaled our documentation site to better meet the needs of users by migrating to the Astro ecosystem."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/unu6xNHqGPZdNnccHPWhz/b45b02ee55cd04ae92bb01324207cfce/BLOG-2600_OG.png"]}]}],[0,{"id":[0,"2hySj1JFTXmlofjA6IRijm"],"title":[0,"Is this thing on? Using OpenBMC and ACPI power states for reliable server boot"],"slug":[0,"how-we-use-openbmc-and-acpi-power-states-to-monitor-the-state-of-our-servers"],"excerpt":[0,"Cloudflare’s global fleet benefits from being managed by open source firmware for the Baseboard Management Controller (BMC), OpenBMC. This has come with various challenges, some of which we discuss here with an explanation of how the open source nature of the firmware for the BMC enabled us to fix the issues and maintain a more stable fleet."],"featured":[0,false],"html":[0,"\n
At Cloudflare, we provide a range of services through our global network of servers, located in 330 cities worldwide. When you interact with our long-standing application services, or newer services like Workers AI, you’re in contact with one of our fleet of thousands of servers which support those services.
These servers which provide Cloudflare services are managed by a Baseboard Management Controller (BMC). The BMC is a special purpose processor — different from the Central Processing Unit (CPU) of a server — whose sole purpose is ensuring a smooth operation of the server.
Regardless of the server vendor, each server has this BMC. The BMC runs independently of the CPU and has its own embedded operating system, usually referred to as firmware. At Cloudflare, we customize and deploy a server-specific version of the BMC firmware. The BMC firmware we deploy at Cloudflare is based on the Linux Foundation Project for BMCs, OpenBMC. OpenBMC is an open-sourced firmware stack designed to work across a variety of systems including enterprise, telco, and cloud-scale data centers. The open-source nature of OpenBMC gives us greater flexibility and ownership of this critical server subsystem, instead of the closed nature of proprietary firmware. This gives us transparency (which is important to us as a security company) and allows us faster time to develop custom features/fixes for the BMC firmware that we run on our entire fleet.
In this blog post, we are going to describe how we customized and extended the OpenBMC firmware to better monitor our servers’ boot-up processes to start more reliably and allow better diagnostics in the event that an issue happens during server boot-up.
Server systems consist of multiple complex subsystems that include the processors, memory, storage, networking, power supply, cooling, etc. When booting up the host of a server system, the power state of each subsystem of the server is changed in an asynchronous manner. This is done so that subsystems can initialize simultaneously, thereby improving the efficiency of the boot process. Though started asynchronously, these subsystems may interact with each other at different points of the boot sequence and rely on handshake/synchronization to exchange information. For example, during boot-up, the UEFI (Universal Extensible Firmware Interface), often referred to as the BIOS, configures the motherboard in a phase known as the Platform Initialization (PI) phase, during which the UEFI collects information from subsystems such as the CPUs, memory, etc. to initialize the motherboard with the right settings.
\n \n \n
Figure 1: Server Boot Process
When the power state of the subsystems, handshakes, and synchronization are not properly managed, there may be race conditions that would result in failures during the boot process of the host. Cloudflare experienced some of these boot-related failures while rolling out open source firmware (OpenBMC) to the Baseboard Management Controllers (BMCs) of our servers.
\n
\n
Baseboard Management Controller (BMC) as a manager of the host
A BMC is a specialized microprocessor that is attached to the board of a host (server) to assist with remote management capabilities of the host. Servers usually sit in data centers and are often far away from the administrators, and this creates a challenge to maintain them at scale. This is where a BMC comes in, as the BMC serves as the interface that gives administrators the ability to securely and remotely access the servers and carry out management functions. The BMC does this by exposing various interfaces, including Intelligent Platform Management Interface (IPMI) and Redfish, for distributed management. In addition, the BMC receives data from various sensors/devices (e.g. temperature, power supply) connected to the server, and also the operating parameters of the server, such as the operating system state, and publishes the values on its IPMI and Redfish interfaces.
\n \n \n
Figure 2: Block diagram of BMC in a server system.
At Cloudflare, we use the OpenBMC project for our Baseboard Management Controller (BMC).
Below are examples of management functions carried out on a server through the BMC. The interactions in the examples are done over ipmitool, a command line utility for interacting with systems that support IPMI.
\n
# Check the sensor readings of a server remotely (i.e. over a network)\n$ ipmitool <some authentication> <bmc ip> sdr\nPSU0_CURRENT_IN | 0.47 Amps | ok\nPSU0_CURRENT_OUT | 6 Amps | ok\nPSU0_FAN_0 | 6962 RPM | ok\nSYS_FAN | 13034 RPM | ok\nSYS_FAN1 | 11172 RPM | ok\nSYS_FAN2 | 11760 RPM | ok\nCPU_CORE_VR_POUT | 9.03 Watts | ok\nCPU_POWER | 76.95 Watts | ok\nCPU_SOC_VR_POUT | 12.98 Watts | ok\nDIMM_1_VR_POUT | 29.03 Watts | ok\nDIMM_2_VR_POUT | 27.97 Watts | ok\nCPU_CORE_MOSFET | 40 degrees C | ok\nCPU_TEMP | 50 degrees C | ok\nDIMM_MOSFET_1 | 36 degrees C | ok\nDIMM_MOSFET_2 | 39 degrees C | ok\nDIMM_TEMP_A1 | 34 degrees C | ok\nDIMM_TEMP_B1 | 33 degrees C | ok\n\n…\n\n# check the power status of a server remotely (i.e. over a network)\nipmitool <some authentication> <bmc ip> power status\nChassis Power is off\n\n# power on the server\nipmitool <some authentication> <bmc ip> power on\nChassis Power Control: On
\n
Switching to OpenBMC firmware for our BMCs gives us more control over the software that powers our infrastructure. This has given us more flexibility, customizations, and an overall better uniform experience for managing our servers. Since OpenBMC is open source, we also leverage community fixes while upstreaming some of our own. Some of the advantages we have experienced with OpenBMC include a faster turnaround time to fixing issues, optimizations around thermal cooling, increased power efficiency and supporting AI inference.
While developing Cloudflare’s OpenBMC firmware, however, we ran into a number of boot problems.
Host not booting: When we send a request over IPMI for a host to power on (as in the example above, power on the server), ipmitool would indicate the power status of the host as ON, but we would not see any power going into the CPU nor any activity on the CPU. While ipmitool was correct about the power going into the chassis as ON, we had no information about the power state of the server from ipmitool, and we initially falsely assumed that since the chassis power was on, the rest of the server components should be ON. The System Event Log (SEL), which is responsible for displaying platform-specific events, was not giving us any useful information beyond indicating that the server was in a soft-off state (powered off), working state (operating system is loading and running), or that a “System Restart” of the host was initiated.
\n
# System Event Logs (SEL) showing the various power states of the server\n$ ipmitool sel elist | tail -n3\n 4d | Pre-Init |0000011021| System ACPI Power State ACPI_STATUS | S5_G2: soft-off | Asserted\n 4e | Pre-Init |0000011022| System ACPI Power State ACPI_STATUS | S0_G0: working | Asserted\n 4f | Pre-Init |0000011023| System Boot Initiated RESTART_CAUSE | System Restart | Asserted
\n
In the System Event Logs shown above, ACPI is the acronym for Advanced Configuration and Power Interface, a standard for power management on computing systems. In the ACPI soft-off state, the host is powered off (the motherboard is on standby power but CPU/host isn’t powered on); according to the ACPI specifications, this state is called S5_G2. (These states are discussed in more detail below.) In the ACPI working state, the host is booted and in a working state, also known in the ACPI specifications as status S0_G0 (which in our case happened to be false), and the third row indicates the cause of the restart was due to a System Restart. Most of the boot-related SEL events are sent from the UEFI to the BMC. The UEFI has been something of a black box to us, as we rely on our original equipment manufacturers (OEMs) to develop the UEFI firmware for us, and for the generation of servers with this issue, the UEFI firmware did not implement sending the boot progress of the host to the BMC.
One discrepancy we observed was the difference in the power status and the power going into the CPU, which we read with a sensor we call CPU_POWER.
\n
# Check power status\n$ ipmitool <some authentication> <bmc ip> power status\nChassis Power is on\n
\n
However, checking the power into the CPU shows that the CPU was not receiving any power.
\n
# Check power going into the CPU\n$ ipmitool <some authentication> <bmc ip> sdr | grep CPU_POWER \nCPU_POWER | 0 Watts | ok
\n
The CPU_POWER being at 0 watts contradicts all the previous information that the host was powered up and working, when the host was actually completely shut down.
Missing Memory Modules: Our servers would randomly boot up with less memory than expected. Computers can boot up with less memory than installed due to a number of problems, such as a loose connection, hardware problem, or faulty memory. For our case, it happened not to be any of the usual suspects, but instead was due to both the BMC and UEFI trying to simultaneously read from the memory modules, leading to access contentions. Memory modules usually contain a Serial Presence Detect (SPD), which is used by the UEFI to dynamically detect the memory module. This SPD is usually located on an inter-integrated circuit (i2c), which is a low speed, two write protocol for devices to talk to each other. The BMC also reads the temperature of the memory modules via the i2c. When the server is powered on, amongst other hardware initializations, the UEFI also initializes the memory modules that it can detect via their (i.e. each individual memory modules) Serial Presence Detect (SPD), the BMC could also be trying to access the temperature of the memory module at the same time, over the same i2c protocol. This simultaneous attempted read denies one of the parties access. When the UEFI is denied access to the SPD, it thinks the memory module is not available and skips over it. Below is an example of the related i2c-bus contention logs we saw in the journal of the BMC when the host is booting.
\n
kernel: aspeed-i2c-bus 1e78a300.i2c-bus: irq handled != irq. expected 0x00000021, but was 0x00000020
\n
The above logs indicate that the i2c address 1e78a300 (which happens to be connected to the serial presence detect of the memory modules) could not properly handle a signal, known as an interrupt request (irq). When this scenario plays out on the UEFI, the UEFI is unable to detect the memory module.
\n \n \n
Figure 3: I2C diagram showing I2C interconnection of the server’s memory modules (also known as DIMMs) with the BMC
Thermal telemetry: During the boot-up process of some of our servers, some temperature devices, such as the temperature sensors of the memory modules, would show up as failed, thereby causing some of the fans to enter a fail-safe Pulse Width Modulation (PWM) mode. PWM is a technique to encode information delivered to electronic devices by adjusting the frequency of the waveform signal to the device. It is used in this case to control fan speed by adjusting the frequency of the power signal delivered to the fan. When a fan enters a fail-safe mode, PWM is used to set the fan speeds to a preset value, irrespective of what the optimized PWM setting of the fans should be, and this could negatively affect the cooling of the server and power consumption.
In the process of studying the issues we faced relating to the boot-up process of the host, we learned how the power state of the subsystems within the chassis changes. Part of our learnings led us to investigate the Advanced Configuration and Power Interface (ACPI) and how the ACPI state of the host changed during the boot process.
Advanced Configuration and Power Interface (ACPI) is an open industry specification for power management used in desktop, mobile, workstation, and server systems. The ACPI Specification replaces previous power management methodologies such as Advanced Power Management (APM). ACPI provides the advantages of:
Allowing OS-directed power management (OSPM).
Having a standardized and robust interface for power management.
Sending system-level events such as when the server power/sleep buttons are pressed
Hardware and software support, such as a real-time clock (RTC) to schedule the server to wake up from sleep or to reduce the functionality of the CPU based on RTC ticks when there is a loss of power.
From the perspective of power management, ACPI enables an OS-driven conservation of energy by transitioning components which are not in active use to a lower power state, thereby reducing power consumption and contributing to more efficient power management.
The ACPI Specification defines four global “Gx” states, six sleeping “Sx” states, and four “Dx” device power states. These states are defined as follows:
\n
\n
\n
\n
\n
\n
\n
\n
\n \n
\n
\n
Gx
\n
\n
\n
Name
\n
\n
\n
Sx
\n
\n
\n
Description
\n
\n
\n
\n
\n
G0
\n
\n
\n
Working
\n
\n
\n
S0
\n
\n
\n
The run state. In this state the machine is fully running
\n
\n
\n
\n
\n
G1
\n
\n
\n
Sleeping
\n
\n
\n
S1
\n
\n
\n
A sleep state where the CPU will suspend activity but retain its contexts.
\n
\n
\n
\n
\n
S2
\n
\n
\n
A sleep state where memory contexts are held, but CPU contexts are lost. CPU re-initialization is done by firmware.
\n
\n
\n
\n
\n
S3
\n
\n
\n
A logically deeper sleep state than S2 where CPU re-initialization is done by device. Equates to Suspend to RAM.
\n
\n
\n
\n
\n
S4
\n
\n
\n
A logically deeper sleep state than S3 in which DRAM is context is not maintained and contexts are saved to disk. Can be implemented by either OS or firmware.
\n
\n
\n
\n
\n
G2
\n
\n
\n
Soft off but PSU still supplies power
\n
\n
\n
S5
\n
\n
\n
The soft off state. All activity will stop, and all contexts are lost. The Complex Programmable Logic Device (CPLD) responsible for power-up and power-down sequences of various components e.g. CPU, BMC is on standby power, but the CPU/host is off.
\n
\n
\n
\n
\n
G3
\n
\n
\n
Mechanical off
\n
\n
\n
\n
PSU does not supply power. The system is safe for disassembly.
\n
\n
\n
\n
\n
Dx
\n
\n
\n
Name
\n
\n
\n
Description
\n
\n
\n
\n
\n
D0
\n
\n
\n
Fully powered on
\n
\n
\n
Hardware device is fully functional and operational
\n
\n
\n
\n
\n
D1
\n
\n
\n
Hardware device is partially powered down
\n
\n
\n
Reduced functionality and can be quickly powered back to D0
\n
\n
\n
\n
\n
D2
\n
\n
\n
Hardware device is in a deeper lower power than D1
\n
\n
\n
Much more limited functionality and can only be slowly powered back to D0.
\n
\n
\n
\n
\n
D3
\n
\n
\n
Hardware device is significantly powered down or off
\n
\n
\n
Device is inactive with perhaps only the ability to be powered back on
\n
\n
\n \n
\n
\n
The states that matter to us are:
S0_G0_D0: often referred to as the working state. Here we know our host system is running just fine.
S2_D2: Memory contexts are held, but CPU context is lost. We usually use this state to know when the host’s UEFI is performing platform firmware initialization.
S5_G2: Often referred to as the soft off state. Here we still have power going into the chassis, however, processor and DRAM context are not maintained, and the operating system power management of the host has no context.
Since the issues we were experiencing were related to the power state changes of the host — when we asked the host to reboot or power on — we needed a way to track the various power state changes of the host as it went from power off to a complete working state. This would give us better management capabilities over the devices that were on the same power domain of the host during the boot process. Fortunately, the OpenBMC community already implemented an ACPI daemon, which we extended to serve our needs. We added an ACPI S2_D2 power state, in which memory contexts are held, but CPU context is lost, to the ACPI daemon running on the BMC to enable us to know when the host’s UEFI is performing firmware initialization, and also set up various management tasks for the different ACPI power states.
An example of a power management task we carry out using the S0_G0_D0 state is to re-export our Voltage Regulator (VR) sensors on S0_G0_D0 state, as shown with the service file below:
Having set this up, OpenBMC has a Net Function (ipmiSetACPIState) in phosphor-host-ipmid that is responsible for setting the ACPIState of the host on the BMC. This command is called by the host using the standard ipmi command with the corresponding NetFn=0x06 and Cmd=0x06.
In the event of an immediate power cycle (i.e. host reboots without operating system shutdown), the host is unable to send its S5_G2 state to the BMC. For this case, we created a patch to OpenBMC’s x86-power-control to let the BMC become aware that the host has entered the ACPI S5_G2 state (i.e. soft-off). When the host comes out of the power off state, the UEFI performs the Power On Self Test (POST) and sends the S2_D2 to the BMC, and after the UEFI has loaded the OS on the host, it notifies the BMC by sending the ACPI S0_G0_D0 state.
Going back to the boot-up issues we faced, we discovered that they were mostly caused by devices which were in the same power domain of the CPU, interfering with the UEFI/platform firmware initialization phase. Below is a high level description of the fixes we applied.
Servers not booting: After identifying the devices that were interfering with the POST stage of the firmware initialization, we used the host ACPI state to control when we set the appropriate power mode state for those devices so as not to cause POST to fail.
Memory modules missing: During the boot-up process, memory modules (DIMMs) are powered and initialized in S2_D2 ACPI state. During this initialization process, UEFI firmware sends read commands to the Serial Presence Detect (SPD) on the DIMM to retrieve information for DIMM enumeration. At the same time, the BMC could be sending commands to read DIMM temperature sensors. This can cause SMBUS collisions, which could either cause DIMM temperature reading to fail or UEFI DIMM enumeration to fail. The latter case would cause the system to boot up with reduced DIMM capacity, which could be mistaken as a failing DIMM scenario. After we had discovered the race condition issue, we disabled the BMC from reading the DIMM temperature sensors during S2_D2 ACPI state and set a fixed speed for the corresponding fans. This solution allows our UEFI to retrieve all the necessary DIMM subsystems information for enumeration, and our servers now boot up with the correct size of memory.
Thermal telemetry: In S0_G0 power state, when sensors are not reporting values back to the BMC, the BMC assumes that devices may be overheating and puts the fan controller into fail-safe mode where fan speeds are ramped up to maximum speed. However, in S5_G2 state, some thermal sensors like CPU temperature, NIC temperature, etc. are not powered and not available. Our solution is to set these thermal sensors as non-functional in their exported configuration when in S5_G2 state and during the transition from S5_G2 state to S2_D2 state. Setting the affected devices as non-functional in their configuration, instead of waiting for thermal sensor read commands to error out, prevents the controller from entering the fail-safe mode.
Aside from resolving issues, we have seen other benefits from implementing ACPI Power State on our BMC firmware. An example is in the area of our automated firmware regression testing. Various parts of our tests require rebooting/power cycling the servers over a hundred times, during which we monitor the ACPI power state changes of our servers as against using a boolean (running or not running, pingable or not pingable) to assert the status of our servers.
Also, it has given us the opportunity to learn more about the complex subsystems in a server system, and the various power modes of the different subsystems. This is an aspect that we are still actively learning about as we look to further optimize various aspects of the boot sequence of our servers.
In the course of time, implementing ACPI states is helping us achieve the following:
All components are enabled by end of boot sequence,
BIOS and BMC are able to retrieve component information,
And the BMC is aware when thermal sensors are in a non-functional state.\n
For better observability of the boot progress and “last state” of our systems, we have also started the process of adding the BootProgress object of the Redfish ComputerSystem Schema into our systems. This will give us an opportunity for pre-operating system (OS) boot observability and an easier debug starting point when the UEFI has issues (such as when the server isn’t coming on) during the server platform initialization.
With each passing day, Cloudflare’s OpenBMC team, which is made up of folks from different embedded backgrounds, learns about, experiments with, and deploys OpenBMC across our global fleet. This has been made possible by relying on the OpenBMC community’s contribution (as well as upstreaming some of our own contributions), and our interaction with our various vendors, thereby giving us the opportunity to make our systems more reliable, and giving us the ownership and responsibility of the firmware that powers the BMCs that manage our servers. If you are thinking of embracing open-source firmware in your BMC, we hope this blog post written by a team which started deploying OpenBMC less than 18 months ago has inspired you to give it a try.
For those who are interested in considering making the jump to open-source firmware, check it out here!
"],"published_at":[0,"2024-10-22T14:00+01:00"],"updated_at":[0,"2024-10-22T14:29:45.868Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7tXffZR8RhNdDz7mqsydir/41a33236f8eac2ca38d4b5ae9c21a77e/image3.png"],"tags":[1,[[0,{"id":[0,"7fYeYFd6aJXluz5xmGkdZT"],"name":[0,"Infrastructure"],"slug":[0,"infrastructure"]}],[0,{"id":[0,"3txfsA7N73yBL9g3VPBLL0"],"name":[0,"Open Source"],"slug":[0,"open-source"]}],[0,{"id":[0,"2zGeaSPj2uoPFugy8J60n1"],"name":[0,"OpenBMC"],"slug":[0,"open-bmc"]}],[0,{"id":[0,"1IVpRmO1Bg0J9pDI7FUeEB"],"name":[0,"Servers"],"slug":[0,"servers"]}],[0,{"id":[0,"vGIiidDZ4NKOzDrDSfIjN"],"name":[0,"Firmware"],"slug":[0,"firmware"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Nnamdi Ajah"],"slug":[0,"nnamdi"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3FssFdDxuBmbKbJiY4PuNj/e36d48a362480cbc7e38b1017290ad69/nnamdi.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}],[0,{"name":[0,"Ryan Chow"],"slug":[0,"ryan-chow"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5TJGoRJtGt1tLdEfiXF5Zn/3d7cda2f3b5cacd67b8bb1720d8dcc40/ryan-chow.png"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}],[0,{"name":[0,"Giovanni Pereira Zantedeschi"],"slug":[0,"giovanni"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7A7A57tAXHrOynxnx3eFpi/15cfa82b216391c547be01178e30cd98/giovanni.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}]]],"meta_description":[0,"Cloudflare’s global fleet benefits from being managed by open source firmware for the Baseboard Management Controller (BMC), OpenBMC. This has come with various challenges, some of which we discuss here with an explanation of how the open source nature of the firmware for the BMC enabled us to fix the issues and maintain a more stable fleet."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/how-we-use-openbmc-and-acpi-power-states-to-monitor-the-state-of-our-servers"],"metadata":[0,{"title":[0,"Is this thing on? Using OpenBMC and ACPI power states for reliable server boot"],"description":[0,"Cloudflare’s global fleet benefits from being managed by open source firmware for the Baseboard Management Controller (BMC), OpenBMC. This has come with various challenges, some of which we discuss here with an explanation of how the open source nature of the firmware for the BMC enabled us to fix the issues and maintain a more stable fleet."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/LZdIivdHwtFqTFXKQ5uDD/ae1874bac4f578597a346ade6a24f248/Is_this_thing_on"]}]}]]],"locale":[0,"de-de"],"translations":[0,{"posts.by":[0,"VON"],"footer.gdpr":[0,"DSGVO"],"lang_blurb1":[0,"Dieser Beitrag ist auch auf {lang1} verfügbar."],"lang_blurb2":[0,"Dieser Beitrag ist auch auf {lang1} und {lang2} verfügbar."],"lang_blurb3":[0,"Dieser Beitrag ist auch auf {lang1}, {lang2}, und {lang3} verfügbar."],"footer.press":[0,"Presse"],"header.title":[0,"Der Cloudflare-Blog"],"search.clear":[0,"Löschen"],"search.filter":[0,"Filtern"],"search.source":[0,"Quelle"],"footer.careers":[0,"Stellenausschreibungen"],"footer.company":[0,"Unternehmen"],"footer.support":[0,"Support"],"footer.the_net":[0,"theNet"],"search.filters":[0,"Filter"],"footer.our_team":[0,"Unser Team"],"footer.webinars":[0,"Webinare"],"page.more_posts":[0,"Weitere Beiträge"],"posts.time_read":[0,"Lesezeit: {time} Min."],"search.language":[0,"Sprache"],"footer.community":[0,"Community"],"footer.resources":[0,"Ressourcen"],"footer.solutions":[0,"Lösungen"],"footer.trademark":[0,"Markenzeichen"],"header.subscribe":[0,"Abonnieren"],"footer.compliance":[0,"Compliance"],"footer.free_plans":[0,"Free-Tarife"],"footer.impact_ESG":[0,"Impact/ESG"],"posts.follow_on_X":[0,"Folgen auf X"],"footer.help_center":[0,"Hilfe-Center"],"footer.network_map":[0,"Netzwerkkarte"],"header.please_wait":[0,"Bitte warten"],"page.related_posts":[0,"Verwandte Beiträge"],"search.result_stat":[0,"Ergebnisse {search_range} von {search_total} für {search_keyword}"],"footer.case_studies":[0,"Kundenreferenzen"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"Nutzungsbedingungen"],"footer.white_papers":[0,"Studien"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"Community-Hub"],"footer.compare_plans":[0,"Zum Tarifvergleich"],"footer.contact_sales":[0,"Kontakt zum Vertrieb"],"header.contact_sales":[0,"Kontakt zum Vertrieb"],"header.email_address":[0,"E-Mail-Adresse"],"page.error.not_found":[0,"Seite nicht gefunden"],"footer.developer_docs":[0,"Dokumentation für Entwickler"],"footer.privacy_policy":[0,"Datenschutzrichtlinie"],"footer.request_a_demo":[0,"Demo anfragen"],"page.continue_reading":[0,"Weiterlesen"],"footer.analysts_report":[0,"Analyseberichte"],"footer.for_enterprises":[0,"Für Unternehmen"],"footer.getting_started":[0,"Erste Schritte"],"footer.learning_center":[0,"Lernzentrum"],"footer.project_galileo":[0,"Projekt „Galileo“"],"pagination.newer_posts":[0,"Neuere Beiträge"],"pagination.older_posts":[0,"Ältere Beiträge"],"posts.social_buttons.x":[0,"Auf X diskutieren"],"search.icon_aria_label":[0,"Suche"],"search.source_location":[0,"Quelle/Standort"],"footer.about_cloudflare":[0,"Über Cloudflare"],"footer.athenian_project":[0,"Projekt Athenian"],"footer.become_a_partner":[0,"Partner werden"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"Netzwerkservices"],"footer.trust_and_safety":[0,"Vertrauen und Sicherheit"],"header.get_started_free":[0,"Kostenlos loslegen"],"page.search.placeholder":[0,"Cloudflare-Website durchsuchen"],"footer.cloudflare_status":[0,"Cloudflare-Status"],"footer.cookie_preference":[0,"Cookie-Einstellungen"],"header.valid_email_error":[0,"Muss eine gültige E-Mail sein."],"search.result_stat_empty":[0,"Ergebnisse {search_range} von {search_total}"],"footer.connectivity_cloud":[0,"Connectivity Cloud"],"footer.developer_services":[0,"Dienste für Entwickler"],"footer.investor_relations":[0,"Anlegerbeziehungen"],"page.not_found.error_code":[0,"Fehlercode: 404"],"search.autocomplete_title":[0,"Suchanfrage eingeben. Zum Absenden Eingabetaste drücken."],"footer.logos_and_press_kit":[0,"Logos und Pressekit"],"footer.application_services":[0,"Anwendungsservices"],"footer.get_a_recommendation":[0,"Empfehlung erhalten"],"posts.social_buttons.reddit":[0,"Auf Reddit diskutieren"],"footer.sse_and_sase_services":[0,"SSE- und SASE-Dienste"],"page.not_found.outdated_link":[0,"Möglicherweise haben Sie einen veralteten Link verwendet oder die Adresse falsch eingegeben."],"footer.report_security_issues":[0,"Sicherheitsprobleme berichten"],"page.error.error_message_page":[0,"Leider können wir die von Ihnen gewünschte Seite nicht finden."],"header.subscribe_notifications":[0,"Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"Abonnement bestätigt. Danke fürs Abonnieren!"],"posts.social_buttons.hackernews":[0,"Diskutieren Sie auf Hacker News"],"footer.diversity_equity_inclusion":[0,"Diversität, Gleichberechtigung und Inklusion"],"footer.critical_infrastructure_defense_project":[0,"Projekt zur Verteidigung kritischer Infrastruktur"]}],"localesAvailable":[1,[[0,"en-us"],[0,"zh-cn"],[0,"zh-tw"],[0,"fr-fr"],[0,"ja-jp"],[0,"ko-kr"],[0,"es-es"]]],"footerBlurb":[0,"Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.
Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.
Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen."]}" client="load" opts="{"name":"Post","value":true}" await-children="">
Wir weiten unsere Unterstützung für Open Source-Projekte mit dem Projekt Alexandria aus
Wir bei Cloudflare glauben an die Macht von Open Source. Es ist mehr als nur Code, es ist der Geist der Zusammenarbeit, der Innovation und des gemeinsamen Wissensaustauschs, der das Internet vorantreibt. Open Source ist die Grundlage, auf der das Internet gedeiht, und ermöglicht es Entwicklern und Kreativen aus aller Welt, einen Beitrag zu einem größeren Ganzen zu leisten.
Doch oft haben die Open-Source-Betreiber mit den Kosten zu kämpfen, die mit dem Betrieb ihrer Projekte und der Bereitstellung des Zugangs für Nutzer auf der ganzen Welt verbunden sind. Wir hatten das Privileg, unglaubliche Open-Source-Projekte wie Git und die Linux Foundation durch unser Open-Source-Programm zu unterstützen, und haben aus erster Hand erfahren, wo Cloudflare am meisten helfen kann.
Heute stellen wir ein optimiertes und erweitertes Open-Source-Programm vor: Projekt Alexandria. Die antike Stadt Alexandria ist bekannt dafür, dass sie eine reichhaltige Bibliothek und einen Leuchtturm beherbergte, der zu den Sieben Weltwundern der Antike gehörte. Der Leuchtturm von Alexandria diente als Symbol der Kultur und der Gemeinschaft und hieß Menschen aus der Ferne in der Stadt willkommen. Wir sind der Meinung, dass Alexandria eine großartige Metapher für die Rolle ist, die Open-Source-Projekte als Leuchtturm für Entwickler auf der ganzen Welt und als Wissensquelle für die Entwicklung eines besseren Internets spielen.
Dieses Projekt bietet wiederkehrende jährliche Gutschriften für noch mehr Open-Source-Projekte, um unsere Produkte kostenlos zur Verfügung zu stellen. In der Vergangenheit haben wir ein Upgrade auf unseren Pro-Plan angeboten, aber jetzt bieten wir Upgrades an, die auf die Größe und die Bedürfnisse jedes Projekts zugeschnitten sind, zusammen mit dem Zugang zu einer breiteren Palette von Produkten wie Workers, Pages und mehr. Mit dem Projekt Alexandria wollen wir sicherstellen, dass jedes OSS-Projekt nicht nur überlebt, sondern auch gedeiht. Dazu bieten wir Zugang zu den verbesserten Sicherheits-, Performance-Optimierungs- und Entwicklertools von Cloudflare – und das alles zum Nulltarif.
Erstellen Sie ein Programm, das Ihren Bedürfnissen entspricht
Wir wissen, dass Open-Source-Projekte unterschiedliche Anforderungen haben. Bei einigen Projekten, wie z. B. Paket-Repositories, sind die Kosten für die Speicherung und den Transfer am wichtigsten. Andere Projekte benötigen Hilfe beim Schutz vor DDoS-Angriffen. Und manche Projekte benötigen eine robuste Entwicklungsplattform, damit sie schnell skalierbare und sichere Anwendungen erstellen und einsetzen können.
Mit unserem neuen Programm arbeiten wir mit Ihrem Projekt zusammen und helfen Ihnen dabei, je nach Ihren Bedürfnissen die folgenden Punkte zu erfüllen:
Ein Upgrade auf einen Cloudflare Pro-, Business- oder Enterprise-Tarif, der Ihnen mehr Flexibilität mit mehr Cloudflare-Regeln zur Verwaltung des Traffics, Image-Optimierung mit Polish zur Beschleunigung von Bild-Downloads und verbesserte Sicherheit dank der Web Application Firewall (WAF) und Security Analytics bietet. Mit Page Shield können Sie Ihre Projekte vor potenziellen Bedrohungen und Schwachstellen schützen..
Mehr Anfragen an Cloudflare Workers und Pages, sodass Sie mehr Traffic bewältigen und Ihre Anwendungen global skalieren können.
Mehr R2-Speicherplatz für Builds und Artefakte, damit Sie über den nötigen Platz verfügen, um die Assets Ihres Projekts effizient zu speichern und darauf zuzugreifen.
Erweiterter Zero Trust-Zugriff, einschließlich Remote-Browserisolierung, unbegrenzter Benutzerzahl und erweiterter Speicherung von Aktivitätsprotokollen, um Ihnen tiefere Einblicke in und mehr Kontrolle über die Sicherheit Ihres Projekts zu geben.
Jedes Open-Source-Projekt, das an dem Programm teilnimmt, erhält zusätzliche Ressourcen und Unterstützung über einen eigenen Channel auf unserem Discord-Server. Und wenn es etwas gibt, von dem Sie denken, dass wir Ihnen helfen können, das wir derzeit nicht anbieten, sind wir gerne bereit, Ihnen dabei zu helfen, es umzusetzen.
Viele Open-Source-Projekte liegen innerhalb der Grenzen der großzügigen kostenlosen Tarifs von Cloudflare. Unsere Mission, ein besseres Internet zu schaffen, bedeutet, dass Kosten kein Hindernis für die Erstellung, Sicherung und weltweite Verbreitung Ihrer Open-Source-Pakete sein sollten, unabhängig von der Größe des Projekts. Indie- oder Nischen-Open-Source-Projekte können immer noch kostenlos laufen, ohne dass Credits erforderlich sind. Für größere Open-Source-Projekte stehen Ihnen die jährlich wiederkehrenden Credits zur Verfügung, so dass Sie Ihr Geld weiterhin in Innovationen investieren können, anstatt für die Infrastruktur zur Speicherung, Sicherung und Bereitstellung Ihrer Pakete und Websites zu bezahlen.
Wir möchten Projekte unterstützen, die nicht nur innovativ sind, sondern auch für das weitere Wachstum und die Funktionsfähigkeit des Internets entscheidend sind. Die Kriterien für das Programm bleiben die gleichen:
Wir haben das unglaubliche Glück, dass wir Open-Source-Projekte, die wir bewunder, und die unglaublichen Menschen hinter diesen Projekten in unser Programm aufzunehmen – darunter die OpenJS Foundation, OpenTofu und JuliaLang.
OpenJS Foundation
Node.js ist seit 2019 Teil unseres OSS-Programms, und wir haben uns kürzlich mit der OpenJS Foundation zusammengetan, um technischen Support und Infrastrukturverbesserungen für andere wichtige JavaScript-Projekte zu bieten, die bei der Foundation gehostet werden, darunter Fastify, jQuery, Electron, und NativeScript.
Ein herausragendes Beispiel für die Verwendung von Cloudflare durch die OpenJS Foundation ist der CDN Worker von Node.js. Die Lösung befindet sich derzeit in der aktiven Entwicklung durch die Teams für Webinfrastruktur und Build von Node.js und zielt darauf ab, alle auf der Website von Node.js bereitgestellten Release-Assets (Binärdateien, Dokumentationen usw.) bereitzustellen.
Aaron Snell erklärte, dass diese Release-Assets derzeit von einem einzigen statischen Ursprungsdateiserver bereitgestellt wird, der von Cloudflare betrieben wird. Das hat bis vor ein paar Jahren gut funktioniert, als bei neuen Versionen Probleme auftraten. Mit einer neuen Version kam es zu einer Cache-Bereinigung, was bedeutete, dass alle Anfragen für die Release-Assets Cache-Fehler waren, was dazu führte, dass Cloudflare direkt an den statischen Dateiserver weiterleitete und diesen überlastete. Da Node.js jede Nacht Builds veröffentlicht, tritt dieses Problem jeden Tag auf.
Der CDN-Worker soll dieses Problem lösen, indem er Cloudflare Workers und R2 nutzt, um Anfragen nach den Release-Assets zu bearbeiten. Dadurch wird die gesamte Last vom statischen Dateiserver genommen, was zu einer verbesserten Verfügbarkeit für Node.js-Downloads und -Dokumentationen führt und letztlich den Prozess langfristig nachhaltiger macht.
OpenTofu
OpenTofu konzentriert sich auf den Aufbau einer freien und offenen Alternative zu proprietären Infrastructure-as-Code-Plattformen. Eine der größten Herausforderungen bestand darin, die Zuverlässigkeit und Skalierbarkeit ihrer Registry zu gewährleisten und gleichzeitig die Kosten niedrig zu halten. Die R2-Speicher- und Caching-Dienste von Cloudflare waren die perfekte Lösung, mit der OpenTofu statische Dateien in großem Umfang bereitstellen konnte, ohne sich Gedanken über Bandbreiten- oder Performance-Engpässe zu machen.
Das OpenTofu-Team stellte fest, dass es für OpenTofu von größter Bedeutung war, die Kosten für den Betrieb der Registry so niedrig wie möglich zu halten, sowohl was die Bandbreite als auch die Personalkosten angeht. Sie mussten jedoch auch sicherstellen, dass die Verfügbarkeit der Registry nahezu 100 % beträgt, da Tausende von Entwicklern bei einem Ausfall der Registry keine Möglichkeit hätten, ihre Infrastruktur zu aktualisieren.
Die Codebasis der Registry (in Go geschrieben) generiert vorab alle möglichen Antworten der OpenTofu Registry-API und lädt die statischen Dateien in einen R2-Bucket hoch. Mit R2 war OpenTofu in der Lage, die Registry im Wesentlichen kostenlos zu betreiben, ohne sich um Server und Skalierungsprobleme kümmern zu müssen.
JuliaLang
JuliaLang ist vor kurzem unserem OSS-Sponsoring-Programm beigetreten, und wir freuen uns darauf, ihre kritische Infrastruktur zu unterstützen, um den reibungslosen Betrieb ihres Ökosystems zu gewährleisten. Ein wichtiger Aspekt dieser Unterstützung ist die Nutzung der Dienste von Cloudflare, um JuliLang bei der Bereitstellung von Paketen für seine Nutzer zu unterstützen.
Laut Elliot Saba wurde Amazon Lightsail von JuliaLang als kosteneffizientes globales CDN für die Zustellung von Datenpaketen an den Nutzerstamm der Firma eingesetzt. Im Zuge eines Anstiegs der Nutzerzahlen hat das Unternehmen aber gelegentlich die Bandbreitenobergrenze überschritten, wodurch erhebliche Cloud-Kosten angefallen sind – ganz zu schweigen von Performance-Einbußen durch Traffic-Spitzen aufgrund einer Überbeanspruchung von VM zur Lastverteilung. Jetzt setzt JuliaLang R2 von Cloudflare ein. Die Geschwindigkeit und Zuverlässigkeit des R2-Objektspeichers übertrifft die der firmeneigenen, innerhalb von Rechenzentren eingesetzten Lösungen bei Weitem. Weil deshalb nun keine Bandbreitengebühren mehr anfallen, kommt JuliaLang jetzt für nicht einmal ein Zehntel der früheren Ausgaben in den Genuss eines schnelleren und zuverlässigeren Service.
Wie können wir helfen?
Wenn Ihr Projekt unseren Kriterien entspricht und Sie Kosten senken und böse Überraschungen bei der Abrechnung vermeiden möchten, sollten Sie sich bei uns bewerben! Wir möchten der nächsten Generation von Open-Source-Projekten dabei helfen, sich im Internet einen Namen zu machen.
Für weitere Informationen und um sich zu bewerben, besuchen Sie unsere neue Webseite zu Projekt „Alexandria“. Sollten Ihnen weitere Projekte bekannt sein, die von dieser Initiative profitieren könnten, lassen Sie es uns bitte wissen!
Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.
Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
You can now add a Deploy to Cloudflare button to your repository’s README when building a Workers application, making it simple for other developers to set up and deploy your project! ...
At Cloudflare, we treat developer content like an open source product. This collaborative approach enables global contributions to enhance quality and relevance for a wide range of users. This year,...
Cloudflare’s global fleet benefits from being managed by open source firmware for the Baseboard Management Controller (BMC), OpenBMC. This has come with various challenges, some of which we discuss here with an explanation of how the open source nature of the firmware for the BMC enabled us to fix the issues and maintain a more stable fleet....