New category: in-container runtime firewall

GoodBoy Guard

The first in-container runtime firewall that protects containers from the inside.

Stop attacks inside your containers — where edge WAFs, scanners, and host tools can't see.

GoodBoy Guard lives next to your app as a runtime firewall, supervisor, and sandbox that travels with your image, turning every container into a self-defending unit.

Runtime firewallPID 1 supervisorSandbox-lite / OS hardeningSelf-defending containers

terminal

docker run goodboysec/cli patch-dockerfile

Note: the GoodBoy Guard CLI isn't published yet — this command will fail until we push the initial proof of concept.

Runs anywhere you run containers:Docker / KubernetesFly.ioRender.comECS / FargateCloud Run

The Runtime Gap

Your stack already has WAF, scanners, and EDR

Edge WAF

Stops at the perimeter
Blind to internal traffic
Can't hot-patch rules
No container context

GoodBoy Guard

Lives inside each container, next to your app
Sees internal and east–west traffic edge WAFs can't
Reduces exploitation surface and exfiltration attempts inside the container
Hot-patches security rules without redeploys
Complements edge WAF, SCA, and host tools by filling the runtime gap

01Your stack today

Your stack probably already has:

Edge WAF (Cloudflare, AWS WAF) – protects the perimeter.
SCA & scanners (Snyk, Dependabot) – keep dependencies in better shape.
Host runtime / EDR (Falco, EDR, observability) – watch nodes and clusters.

02The blind spot

None of them live inside the container

They sit at the edge or on the host. None of them live inside the container, next to your app, watching real runtime traffic and behavior.

03The runtime gap

That creates a gap:

Internal traffic (service-to-service, post-CDN) isn't inspected by edge WAFs.
Zero-days are exposed between disclosure and redeploy.
RCEs that land in a container can exfiltrate data or pivot internally.
Managed platforms (Fly.io, Render, Fargate, Cloud Run) don't let you install host agents.

GoodBoy Guard closes that gap from inside the container.

Why Now

Containers moved fast. Security lagged behind.

Containers and microservices changed how we ship software. Most security stacks didn't catch up.

Zero-days land faster than patch cycles

Log4Shell-, Spring4Shell-, and React2Shell-class bugs show up regularly. Rebuilding and redeploying every image on short notice is expensive and slow.

Internal traffic is the new attack surface

Edge WAFs see only what hits the perimeter. Real exploits often ride service-to-service calls, SSRF, or traffic that's already behind your CDN, mesh, or API gateway.

Managed platforms hide the host

Fly.io, Render, ECS/Fargate, Cloud Run and friends don't let you install host agents or kernel-level sensors. You still need runtime protection.

Polyglot microservices outgrew language-specific security

A mix of Node, Go, Python, Java, workers, and APIs make it unrealistic to bolt a different library-level WAF into every stack.

GoodBoy Guard exists because modern containers need protection from the inside:

A runtime firewall in every container, with instant virtual patching and behavior-aware controls, so you can keep shipping fast without leaving your runtime blind.

What GoodBoy Guard Is

An in-container runtime firewall that ships with your app

The first in-container runtime firewall for self-defending containers.

Inside every container, next to your app

GoodBoy Guard is a small runtime layer you bake into each container image. It becomes PID 1 inside the container, starts your app, and surrounds it with a runtime firewall, supervisor, and sandbox that travels wherever the image runs.

Runtime firewallPID 1 supervisorSandbox-lite / OS hardening

What it does in every container

Terminates traffic through a reverse proxy + WAF in front of your app.
Applies runtime behavior rules and OS hardening from inside the container.

Why it matters

Hot-patches security rules without requiring a redeploy.
Monitors and contains suspicious processes and usage local to that container.

Instead of a single perimeter WAF or a host agent, you get a runtime firewall inside every container, with rules and protections that travel with the image wherever it runs.

Think of it as self-defense for each container: every image gets its own built-in firewall, anomaly detector, and sandbox – with rules that move wherever the image is deployed.

In one glance

Ships with your image. No code changes; Guard rides along in every container you build.
Becomes PID 1. Starts, supervises, and hardens your app process from inside the container.
Protects at runtime. Blocks bad requests, observes behavior, and applies sandboxing in real time.

Under the hood, Guard is composed of these core components:

Reverse Proxy

Terminates traffic, enforces WAF before your app.

WAF Engine

Size limits, path/user-agent blocks, regex/advanced checks; fail-closed.

Supervisor

PID 1 runner that starts/monitors/restarts your app.

App Fingerprinter

Detects your stack so the right protection profiles load automatically.

Runtime Behaviour Observer

Learns real traffic patterns to surface anomalies and guide tuning.

Runtime Monitor

Watches processes and usage to catch suspicious runtime activity early.

Sandbox-lite / OS hardening

Non-root defaults, localhost binding, drop risky capabilities, optional read-only rootfs.

Dashboard/Admin

Health, status, events, metrics.

Telemetry

Ship events/metrics to ELK/Loki/Datadog/Prometheus.

At a Glance

What It Does

Block attacks inside the container

WAF and runtime checks run next to your app, blocking scanners, traversal, injection, SSRF attempts, and more — including internal service-to-service abuse.

Virtual patching for zero-days

Ship new rules for vulnerabilities (Log4Shell / React2Shell-class) in seconds, without rebuilding images or redeploying.

Containment when RCE lands

Non-root defaults, dropped capabilities, localhost binding, and planned egress/process rules reduce blast radius and make lateral movement harder.

Resilience and supervision

PID 1 supervisor starts, monitors, and restarts your app, exposes health endpoints for probes, and keeps the container stable.

Portability & platform fit

Because it lives inside the image, Guard works across Docker, Kubernetes, Fly.io, Render.com, ECS/Fargate, and more — wherever your container runs.

Observability & telemetry

Emit events and metrics to your existing stacks: ELK, Loki, Datadog, Prometheus.

Benefits

What You Gain

Block Threats Inside the Container

Edge WAFs see only what hits the perimeter. GoodBoy Guard sees what your app actually sees:

Guard has line of sight to:

Service-to-service requests.
Traffic after proxies/CDNs/meshes.
Local SSRF and internal abuse.

It blocks:

Scanners and fuzzers.
Path traversal.
Injection attempts (SQLi, command injection).
SSRF-style payloads and weird internal hosts.

Virtual Patching in Seconds

When a new exploit drops, you don't want to patch packages in every repo, rebuild every image, and redeploy every service under fire.

With GoodBoy Guard, you can:

Ship focused rules updates for a given CVE or exploit chain.
Have containers pick up the new rule set live.
Shield vulnerable code while you patch at your own pace.

Example: a React2Shell-style bug is disclosed. You roll out a targeted ruleset that blocks related attack patterns in seconds, without touching application code.

Containment and Reduced Blast Radius

If someone does land RCE in a container, Guard helps keep it small:

Non-root by default.
Dropped capabilities limit what the process can do.
Localhost binding limits unexpected exposure.
Egress and process checks can block suspicious outbound calls and child processes.

You turn a potential lateral movement event into a contained, observable incident.

Resilience & Uptime

GoodBoy Guard improves reliability:

PID 1 supervisor restarts crashed apps cleanly.
Health endpoints help orchestrators know when a container is truly healthy.
Guard can fail in controlled modes (monitor-only vs blocking) so you can choose your risk posture.

Security and reliability don't fight each other — they ship together.

Portability & Platform Fit

Because Guard lives inside the image, it:

Works on Docker, Kubernetes, Fly.io, Render.com, ECS/Fargate, Cloud Run, and more.
Doesn't rely on privileged DaemonSets or host agents.
Is ideal for managed container environments where you can't install host security.

Security travels with your container, wherever you run it.

Simplicity

Zero-Config Promise

Add our base image and your start command. That’s it.

Keep your existing configuration and environment; we plug in around your app, not through it.

App fingerprinting loads the right protection profiles automatically, with simple env vars to override defaults when you need them.

Works with new apps, existing images, common language presets and OS bases, and wrapping containers you already run today.

Workflow

How It Works

Add the Guard

Use the CLI to patch your existing Dockerfile or wrap an existing image — no app code changes required.

Fingerprint Your App

On first run, Guard analyzes your stack — language, framework, usual ports, layout — to select a baseline of protection profiles.

Snap-In Profiles

Matching language and framework-aware profiles load automatically; smart merge logic lets later profiles override scalars and append lists to cut false positives.

Guard Every Request

All traffic to your app flows through Guard’s in-container runtime firewall: reverse proxy terminates, WAF inspects, safe traffic is forwarded and malicious attempts are blocked and logged.

Hot Reload & Observe

Guard watches profiles and rules on disk, hot-swapping merged rulesets within seconds — no redeploy — while you watch health, blocks, anomalies, and suspect processes in your dashboard or logging stack.

Add the Guard

Use the CLI to patch your existing Dockerfile or wrap an existing image — no app code changes required.

Fingerprint Your App

On first run, Guard analyzes your stack — language, framework, usual ports, layout — to select a baseline of protection profiles.

Snap-In Profiles

Matching language and framework-aware profiles load automatically; smart merge logic lets later profiles override scalars and append lists to cut false positives.

Guard Every Request

All traffic to your app flows through Guard’s in-container runtime firewall: reverse proxy terminates, WAF inspects, safe traffic is forwarded and malicious attempts are blocked and logged.

Hot Reload & Observe

Get Started

CLI, Dockerfile, and smoke checks

CLI: Add the Guard

terminal

1# 1) Patch your existing Dockerfile
2docker run goodboysec/cli patch-dockerfile

Example Patched Dockerfile

Dockerfile

1# 2) Patched Dockerfile
2FROM goodboysec/node:20-alpine # was node:20-alpine
3WORKDIR /app
4COPY package*.json ./
5RUN npm ci --only=production
6COPY . .
7ENV APP_CMD="npm start"
8ENV APP_PORT=3000
9ENV APP_ROOT="/app"

Build & Run

terminal

1# 3) Build & run your guarded app
2docker compose up --build
3
4# Smoke checks
5curl http://localhost:8080/                     # app through proxy
6curl -i -A "sqlmap" http://localhost:8080/      # hacking attempt blocked

Heads up: the GoodBoy Guard CLI and base images are not published yet. These commands are the intended workflow and will start working as soon as we push the initial PoC.

Profiles

Profile-Based Rules

Fingerprint-based

Guard fingerprints your app to pick the right profiles, so you only load protections relevant to your stack.

Smart Merge Logic

Profiles are merged with clear precedence: later profiles override scalar values, and lists are appended to reduce noisy false positives.

Hot Reload

Edit or add any profile file. Guard detects the change and hot-swaps the merged ruleset into the running container within seconds — no restarts, no redeploys.

Case Study

Real-World: React2Shell

01Before disclosure

Before disclosure

Baseline Guard profiles already make generic exploit chains much harder to land; WAF and runtime rules filter many RCE payloads and traversal attempts.

02At disclosure

At disclosure

A React2Shell-class bug is announced. Your team ships a focused GoodBoy rules update and rolls it out to all guarded containers in seconds — no redeploy required.

03During attacks

During attacks

Suspicious payloads are blocked inline, logged, and surfaced in the dashboard with context — which endpoint, which service, which payload type.

04If exploit lands

If an exploit still lands

Supervisor and sandbox-lite controls reduce what the attacker can do, restart the app, and give you detailed evidence of the attempt so you stay in control while you patch.

Audience

Who It's For

For Developers & DevOps

Who gets the most value

Add security without rewriting code.
Dockerfile patch instead of a months-long “security project”.
See real blocked attacks against your own services.
Reduce fire-drill patching for every CVE.

“Add a guard to your container, not a security tax to your roadmap.”

For Security & Platform Teams

Who gets the most value

Close the runtime blind spot inside containers.
Inline blocking of exploit attempts, not just alerts.
Visibility into per-container behavior and anomalies.
Virtual patching as a compensating control for zero-days.
Works across clouds, clusters, and platforms.

“A runtime layer that actually lives where your apps run.”

For Engineering Leaders & Founders

Who gets the most value

Reduce breach risk and blast radius from container incidents.
Improve resilience and uptime with supervised containers.
Show clear investment in modern runtime security to customers and auditors.
Open-core guard with paid rules feeds and cloud dashboard – an investable platform, not a dead-end add-on.

“Defense-in-depth for containers, with a business model that scales.”

Performance & Safety

Designed for production workloads

GoodBoy Guard is designed for production: a lightweight, PID 1-safe runtime layer with configurable posture and clear fail-behavior controls.

Lightweight by design

Focused, minimal footprint in each container so you get protection without heavy performance tax.

PID 1-safe

Behaves as a proper init: forwards signals, reaps zombies, and plays nicely with orchestrators.

Configurable posture

Run in monitor-only first, then flip selective blocking on with confidence as you harden rules.

Fail-behavior options

Choose how Guard behaves if rules or connections fail — strict fail-closed, or permissive fail-open for critical paths.

You get defense without unexpected surprises in the hot path.

How It's Different

Where GoodBoy Guard fits in your stack

Keep your edge WAF, SCA, and EDR. GoodBoy Guard fills the runtime gap inside each container and plays nicely with the tools you already trust.

Capability	Edge WAF	CNAPP / host runtime tools	In-app security / RASP	GoodBoy Guard
Where it runs	At the perimeter (CDN / gateway).	On nodes and clusters, outside the container.	Inside app code and framework runtime.	Inside each container, next to your app as PID 1.
Traffic it sees	Inbound internet traffic only; no internal/east–west traffic.	Host and cluster activity, not per-container HTTP flows.	Requests that make it into app code.	Real runtime traffic after CDNs, proxies, and meshes, including service-to-service calls.
App & OS awareness	Limited app context, no process/OS view inside the container.	Good host visibility; limited app/container context.	Deep in app logic; minimal OS/process context.	Understands language/framework and observes processes, filesystem, and network in-container.
Fit for managed platforms	Works well at the edge, independent of platform.	Harder on managed platforms (Fargate, Fly, Cloud Run) that don’t expose the host.	Depends on language/runtime support in your platform.	Ideal for managed container platforms; ships with the image and needs no host agents.
How protection travels	Rules live at the perimeter; don’t travel with images.	Policies live with the cluster or host stack.	Tied to specific codebases and languages.	Profiles and hot patches ship with the image and move wherever you deploy.
Language & stack coverage	Language-agnostic, but blind to what happens inside the app/container.	Language-agnostic at host level.	Bound to specific languages/frameworks.	Language-agnostic; protects any containerized app by living alongside it.

Where It Fits in Your Stack

You keep:

Cloudflare / AWS WAF – stop generic threats at the edge.
Snyk / Dependabot – keep dependencies updated.
Falco / EDR / observability – watch hosts and clusters.

You add:

GoodBoy Guard – in-container runtime firewall:

Lives inside each container, next to your app.
Sees real runtime traffic after proxies and CDNs.
Ships profiles and hot patches that travel with your image.
Adds the missing runtime firewall inside each container, where edge and host tools can't see.

Open Core, Rules Feeds, and Cloud Dashboard

GoodBoy Guard is built to compound value over time:

Open-source core – a transparent runtime layer developers can trust.
Paid rule feeds – continuously updated exploit and anomaly signatures you can roll out instantly.
Cloud dashboard – multi-cluster visibility, centralized policy, alerting, and integrations.

Together, they make GoodBoy Guard an investable runtime security layer, not just another checkbox.