The core of the Android operating system, as represented by the Android Open Source Project (AOSP),
can only be considered one of the most successful open-source initiatives
ever created; its user count is measured in the billions. But few would
consider it to be a truly community-oriented project. At the 2024 Linux Plumbers Conference, Chris Simmonds
asked why the AOSP community is so hard to find, and what might be done
about the situation.
Version 2.47.0 of the Git
source-code management system has been released. The changes include a
long list of incremental improvements; see the announcement and this
GitHub blog post for details.
In today’s data-driven landscape, managing and analyzing vast amounts of data, especially logs, is crucial for organizations to derive insights and make informed decisions. However, handling large data while extracting insights is a significant challenge, prompting organizations to seek scalable solutions without the complexity of infrastructure management.
Amazon OpenSearch Serverless reduces the burden of manual infrastructure provisioning and scaling while still empowering you to ingest, analyze, and visualize your time-series data, simplifying data management and enabling you to derive actionable insights from data.
We recently announced a new capacity level of 30TB for time series data per account per AWS Region. The OpenSearch Serverless compute capacity for data ingestion and search/query is measured in OpenSearch Compute Units (OCUs), which are shared among various collections with the same AWS Key Management Service (AWS KMS) key. To accommodate larger datasets, OpenSearch Serverless now supports up to 500 OCUs per account per Region, each for indexing and search respectively, more than double from the previous limit of 200. You can configure the maximum OCU limits on search and indexing independently, giving you the reassurance of managing costs effectively. You can also monitor real-time OCU usage with Amazon CloudWatch metrics to gain a better perspective on your workload’s resource consumption. With the support for 30TB datasets, you can analyze data at the 30TB level to unlock valuable operational insights and make data-driven decisions to troubleshoot application downtime, improve system performance, or identify fraudulent activities.
This post discusses how you can analyze 30TB time series datasets with OpenSearch Serverless.
Innovations and optimizations to support larger data size and faster responses
Sufficient disk, memory, and CPU resources are crucial for handling extensive data effectively and conducting thorough analysis. These resources are not just beneficial but crucial for our operations. In time series collections, the OCU disk typically contains older shards that are not frequently accessed, referred to as warm shards. We have introduced a new feature called warm shard recovery prefetch. This feature actively monitors recently queried data blocks for a shard. It prioritizes them during shard movements, such as shard balancing, vertical scaling, and deployment activities. More importantly, it accelerates auto-scaling and provides faster readiness for varying search workloads, thereby significantly improving our system’s performance. The results provided later in this post provide details on the improvements.
A few select customers worked with us on early adoption prior to General Availability. In these trials, we observed up to 66% improvement in warm query performance for some customer workloads. This significant improvement shows the effectiveness of our new features. Additionally, we have enhanced the concurrency between coordinator and worker nodes, allowing more requests to be processed as the OCUs increases through auto scaling. This enhancement has resulted in up to a 10% improvement in query performance for hot and warm queries.
We have enhanced our system’s stability to handle time-series collections of up to 30 TB effectively. Our team is committed to improving system performance, as demonstrated by our ongoing enhancements to the auto-scaling system. These improvements comprised of enhanced shard distribution for optimal placement after rollover, auto-scaling policies based on queue length, and a dynamic sharding strategy that adjusts shard count based on ingestion rate.
In the following section we share an example test setup of a 30TB workload that we used internally, detailing the data being used and generated, along with our observations and results. Performance may vary depending on the specific workload.
Ingest the data
You can use the load generation scripts shared in the following workshop, or you can use your own application or data generator to create a load. You can run multiple instances of these scripts to generate a burst in indexing requests. As shown in the following screenshot, we tested with an index, sending approximately 30 TB of data over a period of 15 days. We used our load generator script to send the traffic to a single index, retaining data for 15 days using a data life cycle policy.
Test methodology
We set the deployment type to ‘Enable redundancy’ to enable data replication across Availability Zones. This deployment configuration will lead to 12-24 hours of data in hot storage (OCU disk memory) and the rest in Amazon Simple Storage Service (Amazon S3). With a defined set of search performance and the preceding ingestion expectation, we set the max OCUs to be 500 for both indexing and search.
As part of the testing, we observed auto-scaling behavior and graphed it. The indexing took around 8 hours to get stabilized at 80 OCU.
On the Search side, it took around 2 days to get stabilized at 80 OCU.
Observations:
Ingestion
The ingestion performance achieved was consistently over 2 TB per day
Search
Queries were of two types, with time ranging from 15 minutes to 15 days.
OpenSearch Serverless not only supports a larger data size than prior releases but also introduces performance improvements like warm shard pre-fetch and concurrency optimization for better query response. These features reduce the latency of warm queries and improve auto-scaling to handle varied workloads. We encourage you to take advantage of the 30TB index support and put it to the test! Migrate your data, explore the improved throughput, and take advantage of the enhanced scaling capabilities.
Satish Nandi is a Senior Product Manager with Amazon OpenSearch Service. He is focused on OpenSearch Serverless and has years of experience in networking, security and AI/ML. He holds a Bachelor’s degree in Computer Science and an MBA in Entrepreneurship. In his free time, he likes to fly airplanes and hang gliders and ride his motorcycle.
Milav Shah is an Engineering Leader with Amazon OpenSearch Service. He focuses on search experience for OpenSearch customers. He has extensive experience building highly scalable solutions in databases, real-time streaming and distributed computing. He also possesses functional domain expertise in verticals like Internet of Things, fraud protection, gaming and AI/ML. In his free time, he likes to ride cycle, hike, and play chess.
Qiaoxuan Xue is a Senior Software Engineer at AWS leading the search and benchmarking areas of the Amazon OpenSearch Serverless Project. His passion lies in finding solutions for intricate challenges within large-scale distributed systems. Outside of work, he enjoys woodworking, biking, playing basketball, and spending time with his family and dog.
Prashant Agrawal is a Sr. Search Specialist Solutions Architect with Amazon OpenSearch Service. He works closely with customers to help them migrate their workloads to the cloud and helps existing customers fine-tune their clusters to achieve better performance and save on cost. Before joining AWS, he helped various customers use OpenSearch and Elasticsearch for their search and log analytics use cases. When not working, you can find him traveling and exploring new places. In short, he likes doing Eat → Travel → Repeat.
Version 4.20 of
the RPM Package Manager (RPM) has been released. Major changes in this
release include a new plugin to prevent filesystem and network access
by scriptlets, the BuildSystem directive for declaring the
build system to be used by packaged software, and more. LWN covered the development of
RPM 4.20 in September.
In the dynamic evolution of AI and cloud computing, the deployment of efficient and reliable hardware is critical. As we roll out our Gen 12 hardware across hundreds of cities worldwide, the challenge of maintaining optimal thermal performance becomes essential. This blog post provides a deep dive into the robust thermal design that supports our newest Gen 12 server hardware, ensuring it remains reliable, efficient, and cool (pun very much intended).
The importance of thermal design for hardware electronics
Generally speaking, a server has five core resources: CPU (computing power), RAM (short term memory), SSD (long term storage), NIC (Network Interface Controller, connectivity beyond the server), and GPU (for AI/ML computations). Each of these components can withstand different temperature limits based on their design, materials, location within the server, and most importantly, the power they are designed to work at. This final criteria is known as thermal design power (TDP).
The reason why TDP is so important is closely related to the first law of thermodynamics, which states that energy cannot be created or destroyed, only transformed. In semiconductors, electrical energy is converted into heat, and TDP measures the maximum heat output that needs to be managed to ensure proper functioning.
Back in December 2023, we talked about our decision to move to a 2U form factor, doubling the height of the server chassis to optimize rack density and increase cooling capacity. In this post, we want to share more details on how this additional space is being used to improve performance and reliability supporting up to three times more total system power.
Standardization
In order to support our multi-vendor strategy that mitigates supply chain risks ensuring continuity for our infrastructure, we introduced our own thermal specification to standardize thermal design and system performance. At Cloudflare, we find significant value in building customized hardware optimized for our unique workloads and applications, and we are very fortunate to partner with great hardware vendors who understand and support this vision. However, partnering with multiple vendors can introduce design variables that Cloudflare then controls for consistency within a hardware generation. Some of the most relevant requirements we include in our thermal specification are:
Ambient conditions: Given our globally distributed footprint with presence in over 330 cities, environmental conditions can vary significantly. Hence, servers in our fleet can experience a wide range of temperatures, typically ranging between 28 to 35°C. Therefore, our systems are designed and validated to operate with no issue over temperature ranges from 5 to 40°C (following the ASHRAE A3 definition).
Thermal margins: Cloudflare designs with clear requirements for temperature limits on different operating conditions, simulating peak stress, average workloads, and idle conditions. This allows Cloudflare to validate that the system won’t experience thermal throttling, which is a power management control mechanism used to protect electronics from high temperatures.
Fan failure support to increase system reliability: This new generation of servers is 100% air cooled. As such, the algorithm that controls fan speed based on critical component temperature needs to be optimized to support continuous operation over the server life cycle. Even though fans are designed with a high (up to seven years) mean time between failure (MTBF), we know fans can and do fail. Losing a server’s worth of capacity due to thermal risks caused by a single fan failure is expensive. Cloudflare requires the server to continue to operate with no issue even in the event of one fan failure. Each Gen 12 server contains four axial fans providing the extra cooling capacity to prevent failures.
Maximum power used to cool the system: Because our goal is to serve more Internet traffic using less power, we aim to ensure the hardware we deploy is using power efficiently. Great thermal management must consider the overall cost of cooling relative to the total system power input. It is inefficient to burn power consumption on cooling instead of compute. Thermal solutions should look at the hardware architecture holistically and implement mechanical modifications to the system design in order to optimize airflow and cooling capacity before considering increasing fan speed, as fan power consumption proportionally scales to the cube of its rotational speed. (For example, running the fans at twice (2x) the rotational speed would consume 8x more power,)
System layout
Placing each component strategically within the server will also influence the thermal performance of the system. For this generation of servers, we made several internal layout decisions, where the final component placement takes into consideration optimal airflow patterns, preventing pre-heated air from affecting equipment in the rear end of the chassis.
Bigger and more powerful fans were selected in order to take advantage of the additional volume available in a 2U form factor. Growing from 40 to 80 millimeters, a single fan can provide up to four times more airflow. Hence, bigger fans can run at slower speeds to provide the required airflow to cool down the same components, significantly improving power efficiency.
The Extended Volume Air Cooled (EVAC) heatsink was optimized for Gen 12 hardware, and is designed with increased surface area to maximize heat transfer. It uses heatpipes to move the heat effectively away from the CPU to the extended fin region that sits immediately in front of the fans as shown in the picture below.
EVAC heatsink installed in one of our Gen 12 servers. The extended fin region sits right in front of the axial fans. (Photo courtesy of vendor.)
The combination of optimized heatsink design and selection of high-performing fans is expected to significantly reduce the power used for cooling the system. These savings will vary depending on ambient conditions and system stress, but under a typical stress scenario at 25°C ambient temperature, power savings could be as much as 50%.
Additionally, we ensured that the critical components in the rear section of the system, such as the NIC and DC-SCM, were positioned away from the heatsink to promote the use of cooler available air within the system. Learning from past experience, the NIC temperature is monitored by the Baseboard Management Controller (BMC), which provides remote access to the server for administrative tasks and monitoring health metrics. Because the NIC has a built-in feature to protect itself from overheating by going into standby mode when the chip temperature reaches critical limits, it is important to provide air at the lowest possible temperature. As a reference, the temperature of the air right behind the CPU heatsink can reach 70°C or higher, whereas behind the memory banks, it would reach about 55°C under the same circumstances. The image below shows the internal placement of the most relevant components considered while building the thermal solution.
Using air as cold as possible to cool down any component will increase overall system reliability, preventing potential thermal issues and unplanned system shutdowns. That’s why our fan algorithm uses every thermal sensor available to ensure thermal health while using the minimum possible amount of energy.
Components inside the compute server from one of our vendors, viewed from the rear of the server. (Illustration courtesy of vendor.)
1️. Host Processor Module (HPM)
8. Power Distribution Board (PDB)
2️. DIMMs (x12)
9. GPUs (up to 2)
3️. CPU (under CPU heatsink)
10. GPU riser card
4. CPU heatsink
11. GPU riser cage
5. System fans (x4: 80mm, dual rotor)
12. Power Supply Units, PSUs (x2)
6. Bracket with power button and intrusion switch
13. DC-SCM 2.0 module
7. E1.S SSD
14. OCP 3.0 module
Making hardware flexible
With the same thought process of optimizing system layout, we decided to use a PCIe riser above the Power Supply Units (PSUs), enabling the support of up to 2x single wide GPU add-in cards. Once again, the combination of high-performing fans with strategic system architecture gave us the capability to add up to 400W to the original power envelope and incorporate accelerators used in our new and recently announced AI and ML features.
Hardware lead times are typically long, certainly when compared to software development. Therefore, a reliable strategy for hardware flexibility is imperative in this rapidly changing environment for specialized computing. When we started evaluating Gen 12 hardware architecture and early concept design, we didn’t know for sure we would be needing to implement GPUs for this generation, let alone how many or which type. However, highly efficient design and intentional due diligence analyzing hypothetical use cases help ensure flexibility and scalability of our thermal solution, supporting new requirements from our product teams, and ultimately providing the best solutions to our customers.
Rack-integrated solutions
We are also increasing the volume of integrated racks shipped to our global colocation facilities. Due to the expected increase in rack shipments, it is now more important that we also increase the corresponding mechanical and thermal test coverage from system level (L10) to rack level (L11).
Since our servers don’t use the full depth of a standard rack in order to leave room for cable management and Power Distribution Units (PDUs), there is another fluid mechanics factor that we need to consider to improve our holistic solution.
We design our hardware based on one of the most typical data center architectures, which have alternating cold and hot aisles. Fans at the front of the server pull in cold air from the corresponding aisle, the air then flows through the server, cooling down the internal components and the hot air is exhausted into the adjacent aisle, as illustrated in the diagram below.
A conventional air-flow diagram of a standard server where the cold air enters from the front of the server and hot air leaves through the rear side of the system.
In fluid dynamics, the minimum effort principle will drive fluids (air in this case) to move where there is less resistance — i.e. wherever it takes less energy to get from point A to point B. With the help of fans forcing air to flow inside the server and pushing it through the rear, the more crowded systems will naturally get less air than those with more space where the air can move around. Since we need more airflow to pass through the systems with higher power demands, we’ve also ensured that the rack configuration keeps these systems in the bottom of the rack where air tends to be at a lower temperature. Remember that heat rises, so even within the cold aisle, there can be a small but important temperature difference between the bottom and the top section of the rack. It is our duty as hardware engineers to use thermodynamics in our favor.
Conclusion
Our new generation of hardware is live in our data centers and it represents a significant leap forward in our efficiency, reliability, and sustainability commitments. Combining optimal heat sink design, thoughtful fan selection, and meticulous system layout and hardware architecture, we are confident that these new servers will operate smoothly in our global network with diverse environmental conditions, maintaining optimal performance of our Connectivity Cloud.
Come join us at Cloudflare to help deliver a better Internet!
When you walk into a vibrant Code Club, it is easy to see that the young creators are having fun with digital making. But are they actually learning anything? Our recent evaluation has shown that not only are they developing their coding skills, but there are many other benefits.
Code Club is a network of free coding clubs where young people learn how to create with technology. The Raspberry Pi Foundation supports Code Clubs through training and guidance for mentors, and by providing learning resources that lead to meaningful and lasting learning outcomes for the young people attending the clubs.
Founded in the UK in 2012, Code Club has grown into a global movement and has already inspired more than 2 million young people to learn how to build their own apps, games, animations, websites, and so much more. We are incredibly proud of the impact Code Club has already achieved and we want many more young people to benefit. Our ambitious goal for the next decade is to reach 10 million more young people through Code Club.
New impact insights about Code Club
We’re ambitious about Code Club because we know it works. Over the last year, the Durham University Evidence Centre for Education (DECE) conducted an independent evaluation of the programme that confirmed earlier evidence: attending Code Club leads to positive outcomes for young people.
The DECE evaluation showed that young people who attend Code Club build their coding skills. They also become more confident in learning coding, grow their interest in it, and develop a sense of belonging. Researchers observed how each young person has their individual projects to work on, which promote a sense of ownership and personalised learning, but that there are also opportunities for collaboration and celebrating their achievements with other creators in the club.
Young people also develop positive attitudes to coding and a range of life skills such as problem solving and communication. These skills and mindsets prepare young people to confidently engage with emerging technologies and with learning in a broader context.
“Coding is really fun when I know what to do, but sometimes it is hard. But I always keep trying.”
– Code Club creator.
Another finding was that Code Clubs are a place where young people who experience difficulties in formal classroom settings can thrive. This suggests Code Clubs can help educators engage a more diverse group of young people in creating with technology than formal education alone could.
“We see pupils in completely different roles when they are doing these Code Club activities. They enjoy more, and you can see they have skills to do things that we otherwise don’t notice.”
– Code Club mentor.
None of the benefits for young people would be possible without the volunteers who give their time and make Code Clubs the positive learning environments they are. Their support is crucial to young people’s engagement and skill development. The evaluation showed that mentors find the experience of volunteering rewarding, and pointed us towards areas where we can offer further support to help them run engaging, impactful Code Clubs.
“…volunteering with Code Club has helped me feel I’m a useful member of society in my old age, so the benefits have been good for me too.”
– Code Club mentor.
How we’re building on our support for clubs
With AI already transforming so many parts of our lives, learning how to create with technology has never been more important. Generative AI is changing how humans give instructions to computers, and at Code Club, young people can experiment with new technologies such as AI in a safe environment. New projects that support young people to learn about AI technologies will be added to the Code Club Projects site later this month, alongside support for club leaders and mentors on this topic.
The evaluation methods used by the DECE will help us hone our ongoing impact measurement work for Code Clubs running in communities all over the world. As we continue to support Code Clubs, we are taking into account that the independent evaluation ran in school-based Code Clubs in the UK only. In our work to grow the Code Club network across the globe, we are adapting our support and resources for local contexts in collaboration with partners who share their expertise.
This will ensure that Code Clubs can provide a fun, welcoming space for all young people. And while they’re having fun, they will also gain relevant learning experiences that empower them to engage confidently with a world that is being transformed by digital technologies.
If you’re interested in the DECE evaluation’s results, we’ve put together a summary for you to download.
Anyway, this isn’t one of the small rc2’s. But looking at
historical trends, being a bigger rc2 isn’t _that_ unusual, and
nothing in here looks all that odd. Yes, the diffstat may look a
bit unusual, in that we had a global header renaming
(asm/unaligned.h -> linux/unaligned.h) and we had a couple of
reverts that stand out as spikes in the stats, but everything else
looks nice and small.
Cloudflare just blocked the current record DDoS attack: 3.8 terabits per second. (Lots of good information on the attack, and DDoS in general, at the link.)
В точка 6 от приоритетите има доста неща, но ще опитам да ги обобщя: „6. Изменения в Закона за движението по пътищата за въвеждане на множество административни облекчения, вкл. отпадане на стикери, онлайн заявяване на регистрация на автомобил, уведомяване за изтичащи документи и др.“
Законопроектът, който внасям не знам кой поред парламент, се допълва с нови подобрения постоянно. Засега той не е стигнал второ четене, а през други закони са приети две негови части: възможността да плащаме глоби онлайн без преди това да ни връчат фиш присъствено и отпадането на синия талон. До стикерите на предното стъкло за съжаление не се стигаше. Ето списък с оставащите мерки, които са готови за внасяне:
1. Изцяло електронно заявяване на регистрация на автомобил, получаване на табели по куриер или в посочен час в МВР, минаване „на канал“ само в рискови случаи или на избран пункт за ГТП.
2. Отпадане на стикерите от предното стъкло. Излишни са, не носят допълнителна информация. Вторичната идентификация на автомобила, за която в момента служи чипа в екостикера, може да се постигне без да лепим всяка година неща по стъклата.
3. Спиране на пътя (след засичане от камери) с цел връчване на автомобили, чиито собственици имат повече от 5 невръчени електронни фиша или наказателни постановления. Публикуване на отворени данни с рецидивисти (нещо, което поисках със задължително разпореждане като министър, но МВР не изпълни)
4. Достъп на всеки собственик, вкл. юридически лица, до регистрите с автомобили и с нарушения, в т.ч до контролни точки. Достъпът ще е и чрез програмни интерфейси, с цел интеграция и автоматизация, вкл. плащане на много глоби накуп дистанционно от юридически лица.
5. Получаване на уведомления с sms или имейл за изтичащи документи: книжка, преглед, гражданска. След това: автоматизиран контрол, вкл. чрез камерите на АПИ, за липса на преглед и гражданска
6. Попълване на телефонни номера и имейли от базите данни на НАП, НОИ, АПИ, общинските дружества за паркиране, с цел повече хора да получават уведомленията за издаден фиш и тези за изтичащи документи.
7. Промяна на подсъдността на нарушенията за електронни фишове – компетентният съд да е по настоящ адрес на нарушителя, а не по местонарушение. За да не се разкарват шофьори или техни адвокати до другия край на страната, ако искат да обжалват фиш.
8. Премахване на действащия текст за дерегистрация на автомобил, когато той е бил предоставен на неправоспособно лице, ако е собственост на юридическо лице, за да не се вкарва бизнеса в разправии и невъзможност да я ползва, защото наемател или служител е направил глупост.
9. Интеграция на техническите прегледи с данни от тол системата с цел установяване на аномалии и фиктивни технически прегледи на камионите, които не са се връщали в страната.
10. Възможност за използване на камерите на АПИ за скорост, вкл. средна скорост в контролиран участък от пътя.
11. Доказване на образователна степен със справка в регистър или с документ за по-висока образователна степен – напр. ако не намирате дипломата за средно, но имате висше, това да е достатъчно.
12. Подобряване на реда за даване на сведения от свидетели на нарушения, за да могат такива да се подават онлайн, както и да се пази самоличността им.
13. Създаване на възможност за електронно водене на цялата документация за обученията за придобиване на правоспособност, с което да се ограничат злоупотребите.
14. Анулиране на глоби, получени заради невъзможност да се спази законово задължение заради неработеща система на държавата (както стана с невъзможността да се сключват застраховки преди няколко месеца, или ако се срине системата за технически прегледи).
15. Премахване на ръчното потвърждение от служители на МВР за електронни фишове (когато разпознаването на номера е с висока степен на сигурност), с цел избягване на корупция и по-бързо получаване на уведомленията за нарушението.
16. Подобряване на механизмите за разходване на средствата от фонда за пътна безопасност, който се пълни от глоби (в момента няма никаква прозрачност, общините на практика не могат да го ползват, а МВР може да купи каквото си иска, напр. купиха си БМВ-та).
Има много какво да се прави, за да се постигне както облекчение на добросъвестните шофьори, така и ограничаване на опасните такива. И за да прави второто, МВР трябва първо да намали бюрокрацията и да повиши доверието в своите действия чрез прозрачност, иначе всичко ще изглежда като „дайте още пари, докато ние сме в храстите след поредната дупка“.
Смятам, че горните промени са лесни за реализация, а ще подобрят значително както пътната безопасност, така и обслужването на гражданите.
Meet Georgia, a diligent website administrator at a growing e-commerce company. Every day, Georgia juggles multiple tasks, from managing server uptime to ensuring customer data security. One morning, Georgia receives an email from a security researcher who discovered a potential vulnerability on the website. The researcher struggled to find the right contact information, leading to delays in reporting the issue. Georgia realizes the need for a standardized way to communicate with security researchers, ensuring that vulnerabilities are reported swiftly and efficiently. This is where security.txt comes in.
Why security.txt matters
Security.txt is becoming a widely adopted standard among security-conscious organizations. By providing a common location and format for vulnerability disclosure information, it helps bridge the gap between security researchers and organizations. This initiative is supported by major companies and aligns with global security best practices. By offering an automated security.txt generator for free, we aim to empower all of our users to enhance their security measures without additional costs.
In 2020, Cloudflare published the Cloudflare Worker for the security.txt generator as an open-source project on GitHub, demonstrating our commitment to enhancing web security. This tool is actively used by Cloudflare to streamline vulnerability disclosure processes. However, over the past few years, we’ve observed a growing demand from our customers for an easier way to implement this standard. In response to this demand and to further support the adoption of security.txt across the Internet, we integrated it directly into our dashboard, making it simple for all our users to enhance their security practices. You can learn more about the initial release and its impact in our previous blog post here.
Who can use the free Cloudflare security.txt generator
This feature is designed for any Cloudflare user who manages a website, from small business owners to large enterprises, from developers to security professionals. Whether you’re a seasoned security expert or new to website management, this tool provides an easy way to create and manage your security.txt file in your Cloudflare account, ensuring that you’re prepared to handle vulnerability reports effectively.
Technical insights: leveraging Cloudflare’s tools
Our security.txt generator is seamlessly integrated into our dashboard. Here’s how it works:
When the user enters their data in the Cloudflare Dashboard, the information is immediately stored in a highly available and geo-redundant PostgreSQL database. This ensures that all user data is securely kept and can be accessed quickly from any location within our global network.
Instead of creating a static file at the point of data entry, we use a dynamic approach. When a request for the security.txt file is made via the standard .well-known path specified by RFC 9116, our system dynamically constructs the file using the latest data from our database. This method ensures that any updates made by users are reflected in real-time without requiring manual intervention or file regeneration. The data entered by users is synchronized across Cloudflare’s global network using our Quicksilver technology. This allows for rapid propagation of changes, ensuring that any updates to the security.txt file are available almost instantaneously across all servers.
Each security.txt file includes an expiration timestamp, which is set during the initial configuration. This timestamp helps alert users when their information may be outdated, encouraging them to review and update their details regularly. For example, if a user sets an expiration date 365 days into the future, they will receive notifications as this date approaches, prompting them to refresh their information.
To ensure compliance with best practices, we also support optional fields such as encryption keys and signatures within the security.txt file. Users can link to their PGP keys for secure communications or include signatures to verify authenticity, enhancing trust with security researchers.
Users who prefer automation can manage their security.txt files through our API, allowing seamless integration with existing workflows and tools. This feature enables developers to programmatically update their security.txt configurations without manual dashboard interactions.
Users can also find a view of any missing security.txt files via Security Insights under Security Center.
Available now, and free for all Cloudflare users
By making this feature available to all our users at no cost, we aim to support the security efforts of our entire community, helping you protect your digital assets and foster trust with your audience.
With the introduction of our free security.txt generator, we’re taking a significant step towards simplifying security management for everyone. Whether you’re a small business owner or a large enterprise, this tool empowers you to adopt industry best practices and ensure that you’re ready to handle vulnerability reports effectively. Set up security.txt on your websites today!
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.