chrisanderton/compile-tyk-plugin repository overview

⁠compile-tyk-plugin

A modern, low-CVE compiler for Tyk Gateway Go plugins. Community / unofficial, not affiliated with Tyk. It builds your plugin against the exact Go toolchain and vendored Gateway source for a given Gateway version, so the resulting .so satisfies plugin.Open's strict ABI requirements, while the image itself stays small and hardened.

• Per-version, ABI-correct builds. Pins the Gateway's exact Go version, -trimpath, build tags and dependency graph, so plugins load cleanly into the matching Gateway.
• Modern hardened base. The default image is built on a Docker Hardened Image (busybox-glibc), native-only. Also published: a -x variant that adds cross toolchains (cross-compiles amd64/arm64/s390x), and a Chainguard -wolfi variant (native-only, lowest CVE count). Old-glibc compatibility comes from an isolated link sysroot, not from shipping an old OS.
• Portable glibc floor. Plugins link against a glibc 2.17 floor (RHEL 7 / CentOS 7 and newer), so they load on the Gateway runtime and on older native hosts alike.
• SBOM and provenance attestations attached to every published image.

⁠Quick start

You don't compile anything yourself — pull the prebuilt image for your Gateway version and run it over your plugin's source (the directory with your main.go / go.mod):

docker run --rm \
  -v "$PWD:/plugin-source" \
  chrisanderton/compile-tyk-plugin:v5.13.0 \
  my-plugin.so

This produces my-plugin_v5.13.0_linux_<arch>.so next to your source.

⁠Editions

Select the Gateway edition at build time with -e EDITION:

docker run --rm -e EDITION=ee-fips -v "$PWD:/plugin-source" \
  chrisanderton/compile-tyk-plugin:v5.13.0 my-plugin.so

Build the plugin with the same edition as the Gateway you'll run it in. For ee-fips the compiler applies whichever FIPS mechanism the target Gateway was built with: Go's native FIPS-140-3 module (GOFIPS140) on recent Gateways (Go 1.24+, e.g. v5.13.0), or the legacy GOEXPERIMENT=boringcrypto on older ones, so the plugin's crypto matches.

⁠Architectures

Plugin targets: linux/amd64, linux/arm64, linux/s390x. The default :vX.Y.Z image is native-only — it builds for its own host arch (amd64→amd64, arm64→arm64). To cross-compile to a different target arch (or s390x), use the -x image with -e GOARCH:

docker run --rm -e GOARCH=s390x -v "$PWD:/plugin-source" \
  chrisanderton/compile-tyk-plugin:v5.13.0-x my-plugin.so

(EE and EE-FIPS publish amd64 and arm64 only, matching Tyk's published Gateways.)

⁠Variants

Three image variants are published for every version. They produce identical plugins — choose by your build needs and supply-chain preferences:

Use the default for native builds; use -x when you need cross-compilation or s390x; use -wolfi for the lowest CVE count, where native-only builds are acceptable.

⁠glibc floor

All variants link plugins against a glibc 2.17 sysroot, loadable on RHEL 7 (ELS) and everything newer — independent of the base OS glibc. (The floor is parameterized; an optional higher-floor tag such as -glibc2.31 can be built for the rare plugin whose own C code needs a glibc function newer than 2.17, at the cost of dropping RHEL 7 compatibility.)

⁠Tags

The -x and -wolfi variants follow the same scheme — e.g. :vX.Y.Z-x, :vX.Y.Z-x-YYYYMMDD, :vX.Y.Z-wolfi, :vX.Y.Z-wolfi-YYYYMMDD.

⁠Loading the plugin

Tyk resolves a plugin path by inserting the version, OS and arch, so deploy and reference the suffixed filename the compiler emits:

plugin_<gateway-version>_linux_<arch>.so

Point your API definition's plugin path at it (Tyk expands plugin.so to that name).

⁠Security and provenance

Built on a hardened base; each image carries an SPDX SBOM and SLSA build provenance attestation.