Conversation
This merge introduces the foundational Dockerfile for the Runtime Node project, establishing a secure, distroless, multi-architecture Node.js runtime image built entirely from a scratch base. The build uses a two-stage approach where the Alpine-based builder stage is responsible for preparing the `/tmp` directory with correct sticky bit permissions, generating a minimal DNS configuration via `nsswitch.conf`, and serving as the source for all necessary runtime artifacts. The final scratch-based image includes only what is required to execute a Node.js process: the musl dynamic linker, `libstdc++`, `libgcc_s`, the Node.js binary, and CA certificates for TLS support. All filesystem entries are set to `555` permissions to enforce a read-only, minimal-privilege environment. The `NODE_ENV` is hardcoded to `production`, and full OCI-compliant image metadata is embedded as labels for traceability and discoverability. No application code is included in this image — it is intended to serve purely as the base runtime layer on top of which application images will be built. There are no migration steps or breaking changes. Rollback is as simple as reverting this file prior to building.
…" branch This merge introduces the complete CI/CD automation layer for the Runtime Node project, delivered through two dedicated GitHub Actions workflow files. The PR testing workflow (`pr-tests.yml`) activates on every pull request targeting either `main` or `develop`, running a sequential pipeline that first lints the Dockerfile via Hadolint with a warning-level failure threshold, then builds the image across both `linux/amd64` and `linux/arm64` using a matrix strategy and subjects it to four automated integrity tests: confirming the Node.js binary is functional, verifying no shell binary is present, verifying no package manager binary is present, and asserting that `NODE_ENV` is set to `production`. This guarantees that the distroless contract is machine-verified on every proposed change before it can be merged. The deployment workflow (`deployment.yml`) activates on pushes to any `v*` tag and handles the full production release process — building and pushing the multi-platform image simultaneously to Docker Hub under `runtimenode/runtime-node` and to GHCR under `ghcr.io/Runtimes-Node/runtime-node`, with both provenance and SBOM attestations enabled. Image tags are managed automatically through `docker/metadata-action`, producing both a version-specific tag and a `latest` alias per release. GHA layer caching is enabled in both workflows to keep build times efficient across repeated runs. There are no application code changes in this merge and no migration steps required. Secrets (`DOCKERHUB_USERNAME`, `DOCKERHUB_TOKEN`) must be configured in the repository settings before the deployment workflow can successfully push to Docker Hub; GHCR access is handled automatically via the built-in `GITHUB_TOKEN`. Rollback, if ever needed, is as straightforward as removing or disabling the relevant workflow file.
…ranch This merge introduces the complete public-facing documentation layer for the Runtime Node project. The README provides a thorough account of what the image is, the security and size rationale behind it, and a concrete comparison against the two most commonly used Node.js base images — demonstrating Runtime Node's advantages in image size, attack surface, distroless status, and supply chain transparency. It includes a ready-to-use multi-stage Dockerfile example, quick start commands for both Docker Hub and GHCR, and a full breakdown of the CI/CD quality guarantees and versioning policy enforced on every release. The CONTRIBUTING guide establishes the canonical reference for all future contributors, codifying every aspect of the development workflow: the three-branch model, branch naming conventions, the Conventional Commits requirement, the exact PR title and description structure the project expects, a detailed walkthrough of the automated CI pipeline and its four per-platform integrity tests, a formal declaration of the distroless guarantee listing every permitted image component by path and purpose, the tag-triggered release process, and the hard Dockerfile constraints that must never be violated. The project icon introduced under `.github/assets/icon.svg` provides the visual identity referenced across both documents. There are no code or image changes in this merge, no migration steps required, and no behavioral impact on the published image.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR promotes the
release/v1.0.0-24.13.1branch intomain, marking the first stable, production-ready release of Runtime Node. It consolidates all work that was developed, reviewed, and validated ondevelopacross three prior merges — the distroless Dockerfile, the full CI/CD automation pipeline, and the complete project documentation — into the stable production branch for the first time.Merging this PR into
mainwill make the codebase release-ready. The deployment workflow is configured to trigger automatically on av1.0.0-24.13.1tag push tomain, which will build and publish the multi-platform image to both Docker Hub (runtimenode/runtime-node) and GHCR (ghcr.io/Runtimes-Node/runtime-node) with provenance attestations and an SBOM attached.Files Changed
Added:
.github/assets/icon.svgworkflows/deployment.ymlpr-tests.ymlCONTRIBUTING.mdDockerfileREADME.mdModified:
Deleted:
Key Changes
Dockerfile— a two-stage scratch-based build that extracts only the Node.js binary, musl libc,libstdc++,libgcc_s, CA certificates, a/tmpmount point, and a minimalnsswitch.conffromnode:24.13.1-alpine3.22, assembling a distroless runtime image withNODE_ENV=productionbaked in and full OCI metadata labels applied..github/workflows/pr-tests.yml— a CI workflow triggered on PRs targetingmainordevelopthat lints the Dockerfile with Hadolint, then builds and validates the image acrosslinux/amd64andlinux/arm64with four integrity tests: Node.js binary smoke test, no-shell check, no-package-manager check, andNODE_ENV=productionvalidation..github/workflows/deployment.yml— a release workflow triggered onv*tag pushes that builds the multi-platform image and publishes it to both Docker Hub and GHCR with provenance and SBOM attestations, usingdocker/metadata-actionfor automatic tag generation including alatestalias.README.md— full project documentation covering what the image is, the security rationale, a feature comparison table againstnode:latestandnode:alpine, quick start commands, a complete multi-stage usage example, registry and platform information, CI/CD quality guarantees, versioning policy, and an acknowledgements section.CONTRIBUTING.md— the complete contributor reference covering branch strategy, branch naming conventions, Conventional Commits format, PR structure requirements, the CI pipeline walkthrough, the distroless guarantee manifest, the release process, and hard Dockerfile constraints..github/assets/icon.svg— the project's SVG icon referenced across bothREADME.mdandCONTRIBUTING.md.