Zum Inhalt springen

Cloudflare Release Notes

Einträge
1.629
Quellen
14
Zuletzt aktualisiert

Folge Cloudflare, um die Release Notes in deinen Feed zu holen.

Developer Platform von Cloudflare

Deploy Hooks für Workers Builds verfügbar

Workers Builds unterstützt Deploy Hooks, also eindeutige URLs pro Branch, die per HTTP-POST einen Build und Deploy auslösen, etwa aus einem CMS, per Cron Trigger oder Slack-Bot.

Workers Builds now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request.

Each Deploy Hook is a unique URL tied to a specific branch. Send it a POST and your Worker builds and deploys.

curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/<DEPLOY_HOOK_ID>"

To create one, go to Workers & Pages > your Worker > Settings > Builds > Deploy Hooks.

Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a Cron Trigger can rebuild your project on a schedule:

export default {
	async scheduled(event, env, ctx) {
		ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
	},
};
export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
    ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
  },
} satisfies ExportedHandler<Env>;

You can also use Deploy Hooks to rebuild when your CMS publishes new content or deploy from a Slack slash command.

Built-in optimizations

…

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Neue L4-Transport-Telemetriefelder in Workers

In request.cf stehen nun die Felder clientTcpRtt, clientQuicRtt und edgeL4 mit Layer-4-Telemetrie der Client-Verbindung wie Round-Trip-Time und Datenübertragungsrate zur Verfügung.

Three new properties are now available on request.cf in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes.

Previously, this telemetry was only available via the Server-Timing: cfL4 response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization.

New properties

Property

Type

Description

clientTcpRtt

number | undefined

The smoothed TCP round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for TCP connections (HTTP/1, HTTP/2). For example, 22.

clientQuicRtt

number | undefined

The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for QUIC connections (HTTP/3). For example, 42.

edgeL4

Object | undefined

Layer 4 transport statistics. Contains deliveryRate (number) — the most recent data delivery rate estimate for the connection, in bytes per second. For example, 123456.

Example: Log connection quality metrics

export default {
  async fetch(request) {
    const cf = request.cf;

    const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0; …

Originalquelle(öffnet in neuem Tab)Problem melden

Consumer Services von Cloudflare

Erweiterter Routing-Bereich auf Cloudflare Radar

Der Routing-Bereich auf Cloudflare Radar ist nun in Unterseiten für Übersicht, RPKI und Anomalien gegliedert und enthält eine neue Top-100-AS-Tabelle.

Radar

Radar now features an expanded Routing section ↗︎ with dedicated sub-pages, providing a more organized and in-depth view of the global routing ecosystem. This restructuring lays the groundwork for additional routing features and widgets coming in the near future.

Dedicated sub-pages

The single Routing page has been split into three focused sub-pages:

  • Overview ↗︎ — Routing statistics, IP address space trends, BGP announcements, and the new Top 100 ASes ranking.
  • RPKI ↗︎ — RPKI validation status, ASPA deployment trends, and per-ASN ASPA provider details.
  • Anomalies ↗︎ — BGP route leaks, origin hijacks, and Multi-Origin AS (MOAS) conflicts.

Screenshot of the routing section menu

New widgets

The routing overview now includes a Top 100 ASes table ranking autonomous systems by customer cone size, IPv4 address space, or IPv6 address space. Users can switch between rankings using a segmented control. …

Originalquelle(öffnet in neuem Tab)Problem melden

Core Platform von Cloudflare

Neue Felder für QUIC-RTT und Zustellrate

Regelausdrücke bieten nun die Felder cf.timings.client_quic_rtt_msec und cf.edge.l4.delivery_rate für QUIC-RTT und Zustellrate, um transportabhängige Regeln zu ermöglichen.

Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing cf.timings.client_tcp_rtt_msec field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.

Previously, QUIC RTT and delivery rate data was only available via the Server-Timing: cfL4 response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.

New fields

Field

Type

Description

cf.timings.client_quic_rtt_msec

Integer

The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections.

cf.edge.l4.delivery_rate

Integer

The most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request.

Example: Route slow connections to a lightweight origin

Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:

Rule expression:

Originalquelle(öffnet in neuem Tab)Problem melden

Application Performance von Cloudflare

Internes DNS in offener Beta verfügbar

Interne DNS ist jetzt in der offenen Beta für Enterprise-Kunden mit Cloudflare Zero Trust oder Gateway Enterprise verfügbar.

Internal DNS is now in open beta.

Who can use it?

Internal DNS is bundled as a part of Cloudflare Gateway and is now available to every Enterprise customer with one of the following subscriptions:

  • Cloudflare Zero Trust Enterprise
  • Cloudflare Gateway Enterprise

To learn more and get started, refer to the Internal DNS documentation.

Originalquelle(öffnet in neuem Tab)Problem melden

Application Security von Cloudflare

WAF-Release 2026-03-30: Schutz für Fortinet, Magento und Parameter Pollution

Das WAF-Release vom 30. März 2026 fügt Erkennungen für eine Authentifizierungs-Bypass-Schwachstelle in Fortinet-Produkten, HTTP-Parameter-Pollution-Versuche und ungehinderte Datei-Uploads in Magento hinzu.

This week's release introduces new detections for a critical authentication bypass vulnerability in Fortinet products (CVE-2025-59718), alongside three new generic detection rules designed to identify and block HTTP Parameter Pollution attempts. Additionally, this release includes targeted protection for a high-impact unrestricted file upload vulnerability in Magento and Adobe Commerce.

Key Findings

  • CVE-2025-59718: An improper cryptographic signature verification vulnerability in Fortinet FortiOS, FortiProxy, and FortiSwitchManager. This may allow an unauthenticated attacker to bypass the FortiCloud SSO login authentication using a maliciously crafted SAML message, if that feature is enabled on the device.

  • Magento 2 - Unrestricted File Upload: A critical flaw in Magento and Adobe Commerce allows unauthenticated attackers to bypass security checks and upload malicious files to the server, potentially leading to Remote Code Execution (RCE).

Impact

Successful exploitation of the Fortinet and Magento vulnerabilities could allow unauthenticated attackers to gain administrative control or deploy webshells, leading to complete server compromise and data theft.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...2f7f95e9

N/A

Generic Rules - Parameter Pollution - Body

Log

Disabled

This is a new detection.

Cloudflare Managed Ruleset

...319731a4

N/A …

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Neue RFC-9440-mTLS-Zertifikatfelder in Workers

In request.cf.tlsClientAuth gibt es vier neue Felder, die Client-Zertifikat und Zwischenzertifikatkette im RFC-9440-Format enthalten und direkt an den Origin weitergeleitet werden können.

Four new fields are now available on request.cf.tlsClientAuth in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in RFC 9440 ↗︎ format — the same standard format used by the Client-Cert and Client-Cert-Chain HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic.

New fields

Field

Type

Description

certRFC9440

String

The client leaf certificate in RFC 9440 format (:base64-DER:). Empty if no client certificate was presented.

certRFC9440TooLarge

Boolean

true if the leaf certificate exceeded 10 KB and was omitted from certRFC9440.

certChainRFC9440

String

The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediates were sent or if the chain exceeded 16 KB.

certChainRFC9440TooLarge

Boolean

true if the intermediate chain exceeded 16 KB and was omitted from certChainRFC9440.

Example: forwarding client certificate headers to your origin

export default {
  async fetch(request) {
    const tls = request.cf.tlsClientAuth;

    // Only forward if cert was verified and chain is complete
    if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) { …

Originalquelle(öffnet in neuem Tab)Problem melden

Cloudflare One von Cloudflare

Code Mode für MCP server portals

MCP server portals unterstützen Code Mode, der einzelne Tool-Definitionen durch ein einziges code-Tool ersetzt und so die Nutzung des Kontextfensters reduziert; er ist standardmäßig auf allen Portalen aktiv und lässt sich unter Access controls > AI controls abschalten.

MCP server portals support Code Mode MCP server patterns, a technique that reduces context window usage by replacing individual tool definitions with a single code execution tool. Code Mode is turned on by default on all portals.

To turn it off, edit the portal in Access controls > AI controls and turn off Code Mode under Basic information.

When Code Mode is active, the portal exposes a single code tool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typed codemode.* methods for each upstream tool. The generated code runs in an isolated Dynamic Worker environment, keeping authentication credentials and environment variables out of the model context.

To use Code Mode, append ?codemode=search_and_execute to your portal URL when connecting from an MCP client:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

For more information, refer to Code Mode.

Originalquelle(öffnet in neuem Tab)Problem melden

Cloudflare One von Cloudflare

Kontextoptimierung für MCP server portals

MCP server portals bieten über den URL-Parameter optimize_context die Optionen minimize_tools und search_and_execute, die den Token-Verbrauch von Tool-Definitionen im Kontextfenster senken.

MCP server portals support two context optimization options that reduce how many tokens tool definitions consume in the model's context window. Both options are activated by appending the optimize_context query parameter to the portal URL.

minimize_tools

Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special query tool that agents use to retrieve full definitions on demand. This provides up to 5x savings in token usage.

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

search_and_execute

Hides all upstream tools and exposes only two tools: query and execute. The query tool searches and retrieves tool definitions. The execute tool runs the upstream tools in an isolated Dynamic Worker environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal.

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

For more information, refer to Optimize context.

Originalquelle(öffnet in neuem Tab)Problem melden

Cloudflare One von Cloudflare

DLP: Streaming-Scan von ZIP-Dateien ohne Größenlimit pro Datei

DLP scannt ZIP-Dateien nun per Streaming Element für Element, wodurch frühere Dateigrößenbeschränkungen entfallen, der Speicherverbrauch sinkt und auch Office-Dokumente (DOCX, XLSX, PPTX) profitieren, ganz ohne Konfigurationsänderung.

DLP now processes ZIP files using a streaming handler that scans archive contents element-by-element as data arrives. This removes previous file size limitations and improves memory efficiency when scanning large archives.

Microsoft Office documents (DOCX, XLSX, PPTX) also benefit from this improvement, as they use ZIP as a container format.

This improvement is automatic — no configuration changes are required.

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Containers und Sandboxes einfach mit Workers verbinden

Containers und Sandboxes können nun per HTTP direkt Workers-Funktionen und Bindings wie KV oder R2 über outbound- und outboundByHost-Handler aufrufen.

Containers and Sandboxes now support connecting directly to Workers over HTTP. This allows you to call Workers functions and bindings, like KV or R2, from within the container at specific hostnames.

Run Worker code

Define an outbound handler to capture any HTTP request or use outboundByHost to capture requests to individual hostnames and IPs.

export class MyApp extends Sandbox {}

MyApp.outbound = async (request, env, ctx) => {
	// you can run arbitrary functions defined in your Worker on any HTTP request
	return await someWorkersFunction(request.body);
};

MyApp.outboundByHost = {
	"my.worker": async (request, env, ctx) => {
		return await anotherFunction(request.body);
	},
};

In this example, requests from the container to http://my.worker will run the function defined within outboundByHost, and any other HTTP requests will run the outbound handler. These handlers run entirely inside the Workers runtime, outside of the container sandbox.

Access Workers bindings

…

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Durable-Object-Jurisdiction über ctx.id.jurisdiction abrufbar

ctx.id.jurisdiction in einem Durable Object liefert nun die Jurisdiction, in der das Objekt erstellt wurde, für nicht jurisdiktionsbeschränkte Namespaces ist der Wert undefined.

ctx.id.jurisdiction inside a Durable Object now reports the jurisdiction the object was created in — for example "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu") — so you can make region-aware decisions without passing the jurisdiction through method arguments or persisting it in storage. For the full list of ID-construction paths that preserve jurisdiction, refer to the Durable Object ID documentation.

export class RegionalRoom extends DurableObject {
	async fetch(request) {
		// "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu")
		const region = this.ctx.id.jurisdiction;
		return new Response(`Hello from ${region ?? "the default region"}!`);
	}
}

// Worker
export default {
	async fetch(request, env) {
		const stub = env.MY_DURABLE_OBJECT.jurisdiction("eu").getByName("general");
		return stub.fetch(request);
	},
};

ctx.id.jurisdiction is undefined for Durable Objects that were not created in a jurisdiction-restricted namespace. Alarms scheduled before 2026-03-15 also do not have jurisdiction stored; to backfill the value, reschedule the alarm from a fetch() or RPC handler.

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Durable-Object-Jurisdiktion über ctx.id.jurisdiction abrufen

Innerhalb eines Durable Object gibt ctx.id.jurisdiction nun die Jurisdiktion zurück, in der das Objekt erstellt wurde, und ist für Objekte ohne Jurisdiktion undefined.

ctx.id.jurisdiction inside a Durable Object now reports the jurisdiction the object was created in — for example "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu") — so you can make region-aware decisions without passing the jurisdiction through method arguments or persisting it in storage. For the full list of ID-construction paths that preserve jurisdiction, refer to the Durable Object ID documentation.

export class RegionalRoom extends DurableObject {
	async fetch(request) {
		// "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu")
		const region = this.ctx.id.jurisdiction;
		return new Response(`Hello from ${region ?? "the default region"}!`);
	}
}

// Worker
export default {
	async fetch(request, env) {
		const stub = env.MY_DURABLE_OBJECT.jurisdiction("eu").getByName("general");
		return stub.fetch(request);
	},
};

ctx.id.jurisdiction is undefined for Durable Objects that were not created in a jurisdiction-restricted namespace. Alarms scheduled before 2026-03-15 also do not have jurisdiction stored; to backfill the value, reschedule the alarm from a fetch() or RPC handler.

Originalquelle(öffnet in neuem Tab)Problem melden

Consumer Services von Cloudflare

URL-Scanner auf Cloudflare Radar deutlich verbessert

Der URL-Scanner unterstützt jetzt Live-Screenshots, PDF- und JSON-Export, ein überarbeitetes Layout sowie detailliertere Datei- und IP-Informationen.

Radar

Radar ships several improvements to the URL Scanner ↗︎ that make scan reports more informative and easier to share:

  • Live screenshots — the summary card now includes an option to capture a live screenshot of the scanned URL on demand using the Browser Rendering API.
  • Save as PDF — a new button generates a print-optimized document aggregating all tab contents (Summary, Security, Network, Behavior, and Indicators) into a single file.
  • Download as JSON — raw scan data is available as a JSON download for programmatic use.
  • Redesigned summary layout — page information and security details are now displayed side by side with the screenshot, with a layout that adapts to narrower viewports.
  • File downloads — downloads are separated into a dedicated card with expandable rows showing each file's source URL and SHA256 hash.
  • Detailed IP address data — the Network tab now includes additional detail per IP address observed during the scan.

Screenshot of the redesigned URL Scanner summary on Radar

Explore these improvements on the Cloudflare Radar URL Scanner ↗︎.

Originalquelle(öffnet in neuem Tab)Problem melden

Cloudflare One von Cloudflare

DLP: HAR-Dateien erkennen und bereinigen

Gateway enthält ein vordefiniertes DLP-Profil namens Unsanitized HAR, mit dem sich HAR-Datei-Uploads in HTTP-Richtlinien blockieren oder auf ein Bereinigungstool umleiten lassen.

HTTP Archive (HAR) files are used by engineering and support teams to capture and share web traffic logs for troubleshooting. However, these files routinely contain highly sensitive data — including session cookies, authorization headers, and other credentials — that can pose a significant risk if uploaded to third-party services without being reviewed or cleaned first.

Gateway now includes a predefined DLP profile called Unsanitized HAR that detects HAR files in HTTP traffic. You can use this profile in a Gateway HTTP policy to either block HAR file uploads entirely or redirect users to a sanitization tool before allowing the upload to proceed.

How to configure a HAR file policy

In the Cloudflare dashboard ↗︎, go to Zero Trust > Traffic policies > Firewall Policies > HTTP and create a new HTTP policy using the DLP Profile selector:

Selector

Operator

Value

Action

DLP Profile

in

Unsanitized HAR

Then choose one of the following actions:

  • Block: Prevents the upload of any HAR file that has not been sanitized by Cloudflare's sanitizer. Use this for strict environments where HAR file sharing must be disallowed entirely. …

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Workers: Erforderliche Secrets in der Wrangler-Konfiguration deklarieren

Die neue Konfigurationseigenschaft secrets erlaubt es, erforderliche Secret-Namen in der Wrangler-Konfiguration festzulegen, die bei lokaler Entwicklung und Deploy geprüft und als Grundlage für die Typgenerierung genutzt werden.

The new secrets configuration property lets you declare the secret names your Worker requires in your Wrangler configuration file. Required secrets are validated during local development and deploy, and used as the source of truth for type generation.

{
	"secrets": {
		"required": ["API_KEY", "DB_PASSWORD"],
	},
}
[secrets]
required = [ "API_KEY", "DB_PASSWORD" ]

Local development

When secrets is defined, wrangler dev and vite dev load only the keys listed in secrets.required from .dev.vars or .env/process.env. Additional keys in those files are excluded. If any required secrets are missing, a warning is logged listing the missing names.

Type generation

wrangler types generates typed bindings from secrets.required instead of inferring names from .dev.vars or .env. This lets you run type generation in CI or other environments where those files are not present. Per-environment secrets are supported — the aggregated Env type marks secrets that only appear in some environments as optional.

Deploy

wrangler deploy and wrangler versions upload validate that all secrets in secrets.required are configured on the Worker before the operation succeeds. If any required secrets are missing, the command fails with an error listing which secrets need to be set. …

Originalquelle(öffnet in neuem Tab)Problem melden

Core Platform von Cloudflare

Logpush mit präziseren Zeitstempeln

Logpush unterstützt nun Zeitstempelformate mit Millisekunden- oder Nanosekundengenauigkeit, konfigurierbar über timestamp_format in den Ausgabeoptionen.

Logpush now supports higher-precision timestamp formats for log output. You can configure jobs to output timestamps at millisecond or nanosecond precision. This is available in both the Logpush UI in the Cloudflare dashboard and the Logpush API.

To use the new formats, set timestamp_format in your Logpush job's output_options:

  • rfc3339ms — 2024-02-17T23:52:01.123Z
  • rfc3339ns — 2024-02-17T23:52:01.123456789Z

Default timestamp formats apply unless explicitly set. The dashboard defaults to rfc3339 and the API defaults to unixnano.

For more information, refer to the Log output options documentation.

Originalquelle(öffnet in neuem Tab)Problem melden

Core Platform von Cloudflare

Neue mTLS-Zertifikatsfelder für Transform Rules

Transform Rules bieten nun vier neue Felder, die Client-Zertifikate im RFC-9440-Format ausgeben, sodass Ursprünge diese ohne zusätzliche Dekodierung verwenden können.

Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in RFC 9440 ↗︎ format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized Client-Cert and Client-Cert-Chain header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.

Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, :MIIDsT...Vw==:. A chain of intermediates is expressed as a comma-separated list of such values.

New fields

Field

Type

Description

cf.tls_client_auth.cert_rfc9440

String

The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented.

cf.tls_client_auth.cert_rfc9440_too_large

Boolean

true if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false.

cf.tls_client_auth.cert_chain_rfc9440

String

The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB.

cf.tls_client_auth.cert_chain_rfc9440_too_large

Boolean

true if the intermediate chain exceeded 16 KB and was omitted. …

Originalquelle(öffnet in neuem Tab)Problem melden

Cloudflare One von Cloudflare

Gateway: OIDC-Claims-Filter in Firewall-, Resolver- und Egress-Richtlinien

Cloudflare Gateway unterstützt OIDC Claims jetzt als Selektor in Firewall-, Resolver- und Egress-Richtlinien, sodass Administratoren identitätsbasierte Richtlinien anhand benutzerdefinierter Claims des Identity Providers erstellen können.

Cloudflare Gateway now supports OIDC Claims as a selector in Firewall, Resolver, and Egress policies. Administrators can use custom OIDC claims from their identity provider to build fine-grained, identity-based traffic policies across all Gateway policy types.

With this update, you can:

  • Filter traffic in DNS, HTTP, and Network firewall policies based on OIDC claim values.
  • Apply custom resolver policies to route DNS queries to specific resolvers depending on a user's OIDC claims.
  • Control egress policies to assign dedicated egress IPs based on OIDC claim attributes.

For example, you can create a policy that routes traffic differently for users with department=engineering in their OIDC claims, or restrict access to certain destinations based on a user's role claim. …

Originalquelle(öffnet in neuem Tab)Problem melden

Developer Platform von Cloudflare

Containers unterstützen Docker-Hub-Images

Containers können nun voll qualifizierte Docker-Hub-Image-Referenzen (auch private Images) direkt in der Wrangler-Konfiguration verwenden, ohne das Image zuvor in die Cloudflare Registry zu pushen.

Containers now support Docker Hub ↗︎ images. You can use a fully qualified Docker Hub image reference in your Wrangler configuration ↗︎ instead of first pushing the image to Cloudflare Registry.

{
	"containers": [
		{
			// Example: docker.io/cloudflare/sandbox:0.7.18
			"image": "docker.io/<NAMESPACE>/<REPOSITORY>:<TAG>",
		},
	],
}
[[containers]]
image = "docker.io/<NAMESPACE>/<REPOSITORY>:<TAG>"

Containers also support private Docker Hub images. To configure credentials, refer to Use private Docker Hub images.

For more information, refer to Image management.

Originalquelle(öffnet in neuem Tab)Problem melden