[Pijukatel]

• Adds a runtime-skill section for agents running behind a proxy that re-signs HTTPS: how to recognise it, find and verify the CA file, and trust it in the Actor's own Dockerfile.
• Documentation only: the runtime does not touch images or builds. Also notes the /v2/acts 404 caused by old base images such as apify/actor-node:20.

[apify-service-account]

Platform parity:

• With ACTOR_RUNTIME_EXTRA_CA_FILE set, the runtime adds actor-runtime-ca-bundle.pem to the root of the build context. Any COPY . ./ (the default Dockerfile and the templates use one) then puts it in the Actor's working directory, and a pushed file with that name is silently replaced. The platform builds the context exactly as pushed. Not in requirements — builds.ts#L161-L164 · buildkit_image_builder.ts#L352-L363
• The runtime adds ENV SSL_CERT_FILE/REQUESTS_CA_BUNDLE/PIP_CERT/CURL_CA_BUNDLE/GIT_SSL_CAINFO/AWS_CA_BUNDLE/NODE_EXTRA_CA_CERTS after every FROM, so build steps and runs see these extra env vars. They point OpenSSL, requests, pip, curl, git and AWS at Node's bundled Mozilla roots plus the file. That replaces the image's own trust store: CAs the base image or Dockerfile installs (update-ca-certificates, certifi) and a base image's own SSL_CERT_FILE stop applying. The platform builds the Dockerfile unmodified, so the image's own store applies. The requirements say "in addition to the public roots" and don't list these variables among a run's env vars — dockerfile-extra-ca.ts#L22-L37 · dockerfile-extra-ca.ts#L63-L67 · buildkit_image_builder.ts#L352-L363

Reviewed commit: 9df68dd

[apify-service-account]

Platform parity:

• With ACTOR_RUNTIME_EXTRA_CA_FILE set, the runtime adds actor-runtime-ca-bundle.pem to the root of the build context and copies it to /actor-runtime-ca-bundle.pem in every stage. So any COPY . ./ (the default Dockerfile uses one) also puts it in the Actor's working directory, the run's image contains both files, and a pushed file with that name is silently replaced. The platform builds the pushed context as-is. Not in requirements, which say runs are unchanged — builds.ts#L161-L164 · dockerfile-extra-ca.ts#L65-L68 · buildkit_image_builder.ts#L352-L363
• The runtime treats any line starting with from as a FROM instruction and inserts COPY/ARG lines after it. That includes lines inside a RUN heredoc or a backslash continuation, such as a Python from x import y, so the RUN is split and the build breaks. The platform builds the Dockerfile unmodified with the docker/dockerfile:1 frontend, which supports heredocs. Not in requirements — dockerfile-extra-ca.ts#L74-L81 · buildkit_image_builder.ts#L59-L63 · buildkit_image_builder.ts#L352-L390
• In build steps, SSL_CERT_FILE, REQUESTS_CA_BUNDLE, PIP_CERT, CURL_CA_BUNDLE, GIT_SSL_CAINFO and AWS_CA_BUNDLE point at Node's bundled Mozilla roots plus the file. This replaces the image's own trust store, so CAs that the base image or Dockerfile installs (update-ca-certificates, certifi) no longer apply to RUN steps. The platform passes only the user's build args plus BUILDKIT_*, so the image's own store applies. The requirements say the CAs are trusted "in addition to the public roots", which is the opposite — dockerfile-extra-ca.ts#L23-L31 · buildkit_image_builder.ts#L379-L390

Reviewed commit: ab07d9b

[apify-service-account]

Platform parity: Aligned.

Reviewed commit: 32466fc