KrakenD Community Edition 3.0.2

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick KrakenD Community Edition 3.0.2 on Ubuntu 24.04 as the software version, choose your Region, then choose Launch through EC2.

Choose m5.large, your key pair and a security group as described above. KrakenD is light, so size up only for high request rates.

To launch with the AWS CLI instead, replace the values in angle brackets.

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=krakend}]'

For KrakenD Community Edition 3.0.2 on Ubuntu 24.04, the SSH user is ubuntu. Connect with your key pair.

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot generates the certificate, the JWT signing key and a demo token, then starts KrakenD and nginx. Confirm that both services are active and that first boot has finished.

systemctl is-active krakend nginx
sudo test -f /var/lib/sac/data/krakend-firstboot.done && echo FIRSTBOOT_DONE krakend version

active active FIRSTBOOT_DONE KrakenD Version: 3.0.2 Go Version: 1.26.10 Glibc Version: STATIC-CGO-DISABLED

nginx listens on port 443 on every address. KrakenD (8080) and the demo backend (8081) listen on loopback only. Confirm the listeners.

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | sed -E 's/pid=[0-9]+,fd=[0-9]+/.../g' | sort -u

0.0.0.0:22 users:(("sshd",...),("systemd",...)) 0.0.0.0:443 users:(("nginx",...),("nginx",...),("nginx",...)) 127.0.0.1:8080 users:(("krakend",...)) 127.0.0.1:8081 users:(("nginx",...),("nginx",...),("nginx",...)) 127.0.0.53%lo:53 users:(("systemd-resolve",...)) 127.0.0.54:53 users:(("systemd-resolve",...)) [::]:22 users:(("sshd",...),("systemd",...)) [::]:443 users:(("nginx",...),("nginx",...),("nginx",...))

nginx runs one worker per vCPU, so the number of nginx entries matches your instance size.

Read the credentials file. Only root can read it.

sudo cat /root/krakend-credentials.txt

The file looks like this:

# KrakenD Community Edition 3.0.2 - generated on first boot by krakend-firstboot.service
# The JWT signing key and the demo token are unique to this instance; none was baked into the image. Keep this secret. KRAKEND_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/ KRAKEND_CERT_SHA256=<sha256-fingerprint> KRAKEND_CONFIG=/etc/krakend/krakend.json KRAKEND_JWK_FILE=/etc/krakend/jwk-sac.json KRAKEND_JWT_ISSUER=sac-krakend-demo KRAKEND_DEMO_TOKEN=<KRAKEND_DEMO_TOKEN>
#
# nginx (HTTPS) is the only public entry point; KrakenD runs on 127.0.0.1:8080 and the demo backend on 127.0.0.1:8081.
# KRAKEND_DEMO_TOKEN (30 days) opens /v1/secure/users/{id}:
curl -H "Authorization: Bearer <token>" .../v1/secure/users/1
# New demo token:
sudo krakend-demo-token --ttl 3600
# New signing key + token:
sudo krakend-rotate-jwt-key
# Change the name it serves as:
sudo krakend-set-hostname <your-dns-name>
# User guide: https://secureanycloud.com/stacks/krakend-community-edition-3-0-2/

The URL uses the instance's public DNS name from EC2 instance metadata. The certificate also names the public and private IP addresses, so https://<public-ip>/ works too. To serve your own DNS name, follow Step 10.

The shipped configuration declares three endpoints in front of the demo backend. /v1/hello proxies one backend call. /v1/users/{id} calls the backend twice (the user record and the user's orders) and merges both answers into one response.

From the instance itself, call the gateway and trust the instance's own certificate.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt)
curl -s --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/hello" | jq .
curl -s --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/users/1" | jq .
curl -s -o /dev/null -D - --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/hello" | tr -d '\r' | grep -iE '^(HTTP|content-type|x-krakend|strict-transport|x-content)'

{ "message": "Hello from the demo backend on 127.0.0.1:8081, routed through KrakenD", "service": "sac-krakend-demo-backend" } { "orders": { "orders": [ { "id": 1001, "status": "shipped", "total": 42.50 }, { "id": 1002, "status": "processing", "total": 19.99 } ] }, "user": { "email": "ada@example.com", "id": 1, "name": "Ada Lovelace", "plan": "enterprise" } } HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-Krakend: Version 3.0.2 X-Krakend-Completed: true Strict-Transport-Security: max-age=31536000 X-Content-Type-Options: nosniff

From your own machine, call the gateway over the internet. The certificate is self-signed, so -k skips the check. Step 10 covers your own name and certificate.

curl -k https://<public-ip>/v1/users/2

KrakenD answers only the endpoints you declare. Any other path returns 404. A host name the instance does not serve is dropped, as is an absolute URL that tries to use the gateway as a forward proxy to another host (here, the instance metadata address). Nothing answers on port 80. Verify each case.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt) for p in /v1/nope /latest/meta-data/; do curl -s -o /dev/null -w "$p -> %{http_code}\n" --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H$p"; done curl -sk -o /dev/null -w 'unknown host name -> %{http_code}\n' --resolve "other.example:443:127.0.0.1" "https://other.example/v1/hello" curl -sk -o /dev/null -w 'absolute URL for another host -> %{http_code}\n' --request-target 'http://169.254.169.254/latest/meta-data/' -H "Host: $H" https://127.0.0.1/ curl -s -o /dev/null -w 'port 80 -> %{http_code}\n' http://127.0.0.1/ || true

/v1/nope -> 404 /latest/meta-data/ -> 404 unknown host name -> 000 absolute URL for another host -> 000 port 80 -> 000

A result of 000 means the connection was closed without an answer.

/v1/secure/users/{id} is protected by KrakenD's auth/validator. It accepts only an HS256 token signed with this instance's key (/etc/krakend/jwk-sac.json, generated on first boot), issued by sac-krakend-demo, with the role demo. Without a valid token, the request never reaches the backend. Try a request with no token, a bad token and the demo token.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt)
T=$(sudo sed -n 's/^KRAKEND_DEMO_TOKEN=//p' /root/krakend-credentials.txt)
curl -s -o /dev/null -w 'no token -> %{http_code}\n' --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/secure/users/3"
curl -s -o /dev/null -w 'bad token -> %{http_code}\n' -H 'Authorization: Bearer not.a.token' --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/secure/users/3"
curl -s -K <(printf 'header = "Authorization: Bearer %s"\n' "$T") --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/secure/users/3" | jq .

no token -> 401 bad token -> 401 { "email": "grace@example.com", "id": 3, "name": "Grace Hopper", "plan": "starter" }

curl -K reads the header from a file descriptor, so the token never appears on a command line.

Mint more tokens with krakend-demo-token (--sub, --ttl in seconds, --role). A token with another role gets 403.

T2=$(sudo krakend-demo-token --sub alice --ttl 600)
echo "$T2" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | jq -c '{iss, sub, roles}'
H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt)
curl -s -o /dev/null -w 'new token -> %{http_code}\n' -K <(printf 'header = "Authorization: Bearer %s"\n' "$T2") --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H/v1/secure/users/2"

{"iss":"sac-krakend-demo","sub":"alice","roles":["demo"]} new token -> 200

sudo krakend-rotate-jwt-key replaces the signing key, so every older token stops working. It also writes a new demo token and restarts KrakenD.

In production, you will usually point the validator at your identity provider's JWKS URL (jwk_url) instead of a local key. The KrakenD JWT validation documentation covers every option. KrakenD verifies that URL's certificate against the system trust store, which is the store Step 9 checks.

Load balancers and monitoring can use the public /health probe. nginx answers ok only while KrakenD's own /__health reports healthy. KrakenD's internal endpoints are never reachable from the network, and the debug and echo endpoints are switched off even on loopback. Verify both.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt) for p in /health /__health /__debug/ /__echo/ /__stats; do curl -s -o /dev/null -w "public $p -> %{http_code}\n" --cacert /etc/nginx/tls/krakend.crt --resolve "$H:443:127.0.0.1" "https://$H$p"; done curl -s http://127.0.0.1:8080/__health | jq -c '{status}' curl -s -o /dev/null -w 'loopback /__debug/ -> %{http_code}\n' http://127.0.0.1:8080/__debug/

public /health -> 200 public /__health -> 404 public /__debug/ -> 404 public /__echo/ -> 404 public /__stats -> 404 {"status":"ok"} loopback /__debug/ -> 404

If you enable KrakenD's OpenTelemetry exporters later, keep any port they open bound to 127.0.0.1, and never open it in a security group.

Edit /etc/krakend/krakend.json and replace the demo endpoints with your own API. The file uses the KrakenD 3.0 configuration format ("version": 4 and the v3.0 schema); KrakenD 3.0 refuses files that still say "version": 3:

sudo jq -c '{"$schema", version, listen_ip, port}' /etc/krakend/krakend.json

{"$schema":"https://www.krakend.io/schema/v3.0/krakend.json","version":4,"listen_ip":"127.0.0.1","port":8080}

sudo nano /etc/krakend/krakend.json

Each endpoint lists its backends; a backend can be a service on this instance or a private address in your VPC. For example, an endpoint that proxies an orders service on a private host:

{ "endpoint": "/v1/orders/{id}", "method": "GET", "backend": [ { "host": ["http://10.0.1.25:3000"], "url_pattern": "/orders/{id}" } ] }

Keep "listen_ip": "127.0.0.1" (nginx is the public entry point) and leave debug_endpoint and echo_endpoint off. Check the file against KrakenD's built-in schema before you restart, so a typing mistake never takes the gateway down. The unit runs the same check before every start.

sudo krakend check -c /etc/krakend/krakend.json -n

Parsing configuration file: /etc/krakend/krakend.json Syntax OK!

sudo systemctl restart krakend

The demo backend (127.0.0.1:8081) can stay or go; once your own services are behind KrakenD you can remove its server block from /etc/nginx/sites-available/sac-krakend. Whatever you route to, KrakenD cannot reach the instance metadata service (Step 11).

Moving a 2.x configuration: KrakenD 3.0 needs "version": 4. It has no Go plugin support in the Community Edition, although Lua scripts cover many of the same needs. It also dropped the OpenCensus, InfluxDB and separate metrics port components in favor of OpenTelemetry. See KrakenD's upgrade notes, and run krakend check --lint on the result.

CVE-2026-111943 is a Critical advisory. The private keys of eight eMudhra intermediate certificate authorities were compromised, so anyone holding them could issue a certificate that a vulnerable client trusts for any host name. KrakenD verifies certificates with Go's crypto/x509 against the operating system trust store (/etc/ssl/certs), both for its calls to HTTPS backends, JWK URLs and telemetry exporters and for client certificates when you enable mTLS. KrakenD Community Edition 3.0.2 is the fixed release.

This image closes it twice over. KrakenD is built with Go 1.26.10, whose crypto/x509 rejects any chain through the eight intermediates whatever the trust store says. Ubuntu's ca-certificates update (20260816ubuntu0.24.04.1) also removed the roots those chains end in. Run the shipped check to prove both on your own instance.

sudo krakend-cve-2026-111943-check

cve-2026-111943: ok KrakenD 3.0.2 (>= 3.0.2) cve-2026-111943: ok built with Go 1.26.10 (>= 1.26.10) cve-2026-111943: ok Go's distrust list of the 8 eMudhra intermediates is compiled into /usr/local/bin/krakend cve-2026-111943: ok the running KrakenD (pid <pid>) uses the system trust store cve-2026-111943: ok 120 trusted certificates: no eMudhra intermediate and no root of the affected chains cve-2026-111943: ok positive controls (Amazon Root CA 1, ISRG Root X1) present cve-2026-111943: ok ca-certificates 20260816ubuntu0.24.04.1 (>= 20260816ubuntu0.24.04.1) cve-2026-111943: RESULT CLOSED

Run the check again after you add your own CA certificates to the system store or replace the KrakenD binary. If you enable mTLS for clients (enable_mtls), KrakenD also trusts the system store for client certificates unless you set disable_system_ca_pool with an explicit ca_certs list, as KrakenD's advisory recommends.

Point a DNS record at the instance, then set the name the gateway serves. This command mints a new self-signed certificate for the name, updates the nginx host settings, reloads nginx and keeps the name across reboots.

sudo krakend-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, copy it over the generated pair and reload nginx. Running krakend-set-hostname again replaces it with a self-signed one.

sudo install -m 0644 <your-domain>.crt /etc/nginx/tls/krakend.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/tls/krakend.key
sudo nginx -t && sudo systemctl reload nginx

The certificate was generated on this instance and names its own addresses. Only root can read the TLS key and the credentials file, and only root and the krakend group can read the JWT signing key. Verify the certificate and the file permissions.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt)
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
sudo stat -c '%a %U:%G %n' /etc/nginx/tls/krakend.key /etc/nginx/tls/krakend.crt /etc/krakend/jwk-sac.json /etc/krakend/krakend.json /root/krakend-credentials.txt

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-<public-ip-dashed>.compute-1.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost 600 root:root /etc/nginx/tls/krakend.key 644 root:root /etc/nginx/tls/krakend.crt 640 root:krakend /etc/krakend/jwk-sac.json 640 root:krakend /etc/krakend/krakend.json 600 root:root /root/krakend-credentials.txt

The client address comes from the connection. Send a request that claims a different origin in X-Forwarded-For and names another host in X-Forwarded-Host. nginx and KrakenD log it with its real address, and the backend receives only that address and the configured host name.

H=$(sudo sed -n 's#^KRAKEND_URL=https://\(.*\)/$#\1#p' /root/krakend-credentials.txt)
P=$(hostname -I | awk '{print $1}')
curl -sk -o /dev/null --resolve "$H:443:$P" -H 'X-Forwarded-For: 203.0.113.9' -H 'X-Forwarded-Host: evil.example' "https://$H/v1/users/spoof-test" sleep 1
sudo grep -h 'spoof-test' /var/log/nginx/access.log | tail -1 | cut -d' ' -f1,6-9 sudo journalctl -u krakend --no-pager -o cat | grep 'GIN.*spoof-test' | tail -1 | tr -s ' '
sudo grep -h 'users/spoof-test' /var/log/nginx/krakend-demo-backend.log | tail -1

<private-ip> "GET /v1/users/spoof-test HTTP/1.1" 500 [GIN] <time> | 500 | <duration> | <private-ip> | GET "/v1/users/spoof-test" 127.0.0.1 [<time>] "GET /users/spoof-test HTTP/1.1" 404 xff="<private-ip>" xfh="ec2-<public-ip-dashed>.compute-1.amazonaws.com" host="127.0.0.1" ua="KrakenD Version 3.0.2"

The 500 is expected, because the demo backend has no user called spoof-test.

KrakenD runs as the krakend user with no capabilities and no core dumps. It cannot reach the instance metadata service and does not report usage to KrakenD's servers. It does not start before first boot has finished, or with a configuration that fails the schema check. Confirm the unit settings.

systemctl show krakend -p User -p NoNewPrivileges -p ProtectSystem -p ProtectHome -p CapabilityBoundingSet -p IPAddressDeny -p LimitCORE
systemctl cat krakend | grep -E '^(ExecStartPre|Environment)='

IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 LimitCORE=0 CapabilityBoundingSet= User=krakend ProtectHome=yes ProtectSystem=strict NoNewPrivileges=yes Environment=USAGE_DISABLE=1 ExecStartPre=+/usr/local/sbin/krakend-guard ExecStartPre=/usr/local/bin/krakend check -c /etc/krakend/krakend.json -n

The metadata block covers every connection KrakenD makes, including calls to backends you configure. An endpoint whose backend is 169.254.169.254 cannot reach the metadata service from inside the krakend service. nginx and the first-boot unit carry the same block.

SSH accepts keys only, with no root login and no X11 forwarding (/etc/ssh/sshd_config.d/00-sac.conf). Confirm the effective settings.

sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|x11forwarding) '

permitrootlogin no passwordauthentication no x11forwarding no

SecureAnyCloud compiled KrakenD on this image from the unmodified upstream 3.0.2 source, with one dependency raised. GO-2026-6860 (CVE-2026-78661) and GO-2026-6866 (CVE-2026-97045) in golang.org/x/net/html were published on 2026-10-27, after KrakenD's 3.0.2 release. govulncheck finds both reachable in the 3.0.2 module graph as tagged.

The build therefore runs go get golang.org/x/net@v0.62.0, the release that fixes them. Go's minimal version selection also moves golang.org/x/crypto, golang.org/x/sync, golang.org/x/sys and golang.org/x/text up one release each. The build fails if go.mod changes in any other way.

The build record, the resulting go.mod and go.sum, and the govulncheck result ship with the image. List them and check the binary.

ls -l /usr/share/doc/krakend | awk 'NR>1{print $1,$5,$9}' sha256sum /usr/local/bin/krakend sed -n '/^source /,/^toolchain sha256/p' /usr/share/doc/krakend/BUILD-PROVENANCE.txt grep '^Your code' /usr/share/doc/krakend/govulncheck-binary.txt

-rw-r--r-- 3000 BUILD-PROVENANCE.txt -rw-r--r-- 11357 LICENSE -rw-r--r-- 5594 README.md -rw-r--r-- 13676 go.mod -rw-r--r-- 65818 go.sum -rw-r--r-- 301 govulncheck-binary.txt a44ee3b23d61ba792177ede1f5c5d0dcff3a68b1fd120dcaffe1ae89b94e21c6 /usr/local/bin/krakend source https://github.com/krakend/krakend-ce/archive/refs/tags/v3.0.2.tar.gz source sha256 8f05f699e3161ec7396011f5eaf0cf4995f0f9f2ff9b925e044e1668d1bdbaac tag commit 0ecf3bf041136d6a6a44e330ebce2c466485f8d0 go.mod / go.sum as tagged (sha256 afeea0f8d4267d5e1ae23aa17039e67c0c72965b6f18688f6cca2ba3a81c2fd6 / 9d321168d67c267a5472c3a6a6a81868d436c1a410e25f369cbbce654f5ec824), then go get golang.org/x/net@v0.62.0: GO-2026-6860 (CVE-2026-78661) and GO-2026-6866 (CVE-2026-97045) in golang.org/x/net/html were published on 2026-10-27, after upstream's release; resulting lines: golang.org/x/crypto v0.58.0, golang.org/x/net v0.62.0, golang.org/x/sync v0.24.0, golang.org/x/sys v0.49.0, golang.org/x/text v0.43.0 resulting go.mod / go.sum sha256 bd6e4934a282a8324776254b42572d4fecc669a09d32a1857827fc298b98ba0a / af707a6d475826b9b99cfbe0ce011b2354a1a3d7ce0fec70ed80c243371a5664 unmodified graph compiles to 46fc12a2ec8eb0f4239bee84c954b328c34094bddf7a6c6c6b5bfbf423a9de5b (not shipped: GO-2026-6860/6866 reachable) schema https://raw.githubusercontent.com/krakend/krakend-schema/0dab76c651fc6be9e578d7cab8e79674e9840a79/v3.0/krakend.json (sha256 8429674ca1ef8d4519079d36099667653546af7300053adb7c4a0f9a7557d9e6; byte-identical to the schema in upstream's 3.0.2 binary) toolchain go1.26.10 linux/amd64, official tarball https://go.dev/dl/go1.26.10.linux-amd64.tar.gz toolchain sha256 ccfe7ae822d2c2f41f4fe7c956199967a4dac22d0ee0d2b2bfdb440aab3b20c5 Your code is affected by 0 vulnerabilities.

The build is reproducible. Compiling the same source archive, module graph and flags (recorded in BUILD-PROVENANCE.txt) with Go 1.26.10 gives the same SHA-256. It is a static build (CGO_ENABLED=0). The Go toolchain and module cache were used on a temporary in-memory filesystem and are not on the image.

KrakenD writes its startup messages and one line per request (client address and HTTP method included) to the journal. nginx logs public requests to /var/log/nginx/access.log and the demo backend's requests to /var/log/nginx/krakend-demo-backend.log. Read the startup lines from the journal.

sudo journalctl -u krakend --no-pager -o cat | sed 's/\x1b\[[0-9;]*m//g' | grep -E 'Starting KrakenD|Listening on' | tail -2

[KRAKEND] <time> ▶ INFO Starting KrakenD v3.0.2 [KRAKEND] <time> ▶ INFO [SERVICE: Gin] Listening on port: 8080

KrakenD 3.0 also adds the HTTP method to its endpoint log lines (for example [ENDPOINT: GET /v1/users/:id]), so update any log parsing you carried over from KrakenD 2.x.

These are the components and paths on the image:

• KrakenD binary: /usr/local/bin/krakend
• Gateway configuration: /etc/krakend/krakend.json
• JWT signing key (demo endpoint): /etc/krakend/jwk-sac.json
• HTTPS front end: /etc/nginx/sites-available/sac-krakend
• Certificate and key: /etc/nginx/tls/
• Demo backend content: /usr/share/sac-krakend/demo-backend/
• Service units: krakend.service, krakend-firstboot.service, nginx.service
• Metadata block: /etc/systemd/system/krakend.service.d/50-sac-imds-deny.conf (and nginx, first boot)
• Helpers: krakend-set-hostname, krakend-demo-token, krakend-rotate-jwt-key, krakend-cve-2026-111943-check in /usr/local/sbin
• License and build provenance: /usr/share/doc/krakend/
• Instance details: /root/krakend-credentials.txt (mode 0600)

Ubuntu's security updates install automatically, including the ca-certificates trust store KrakenD uses. KrakenD is a single binary that is not managed by apt on this image. KrakenD publishes security fixes for the 3.x line of the Community Edition.

To move to a newer KrakenD release, replace /usr/local/bin/krakend with a newer official release (or your own build). Check your configuration with the new binary, then restart.

sudo /tmp/krakend-<version>/krakend check -c /etc/krakend/krakend.json -n sudo install -m 0755 /tmp/krakend-<version>/krakend /usr/local/bin/krakend && sudo systemctl restart krakend

Read the KrakenD release notes and security advisories first. Run sudo krakend-cve-2026-111943-check after a replacement. SecureAnyCloud publishes updated versions of this image as new KrakenD releases ship.