On-prem / Private Deployment

The public FroggerAPI endpoint at api.froggerapi.io is designed for preview and lower-volume usage. Many of the teams we talk to run Tenable WAS inside strict network boundaries (healthcare, finance, internal-only APIs) and prefer to keep Postman collections and OpenAPI specs inside their own environment.

FroggerAPI is built so that the same conversion engine can run as containers in your VPC or data center. The public site is essentially a thin UI in front of that engine.

High-level architecture

A typical private deployment consists of two containers:

• froggerapi-api – the public-facing REST API that your UI, scripts, or CI/CD call.
• froggerapi-converter – a sidecar or internal service that performs the Postman → OpenAPI conversion.

Both containers run inside your Kubernetes cluster, ECS cluster, or bare-metal environment, behind your own load balancers, WAF, and authentication layers.

If you’re integrating FroggerAPI directly into a Tenable-focused platform, you can colocate it in the same VPC or network segment as Tenable itself and keep all traffic on private links.

Supported deployment patterns

Common patterns we expect to support include:

• AWS ECS / Fargate – API + converter as ECS services behind an internal or internet-facing ALB.
• Kubernetes (EKS, AKS, GKE, on-prem) – API + converter as Deployments/Services, optionally with an Ingress controller.
• Docker Compose / bare-metal – for labs, PoCs, or air-gapped environments where a full orchestrator is not available.

Baseline requirements

At a high level, you will need:

• A container runtime (Docker, containerd, etc.).
• Compute resources sized for your expected Postman collection sizes and concurrency.
• Optional: a database or object store if you want to enable Pro features like history and diffing.
• Connectivity from your tooling (CI, Tenable, internal UIs) to the FroggerAPI endpoint.

How Tenable-focused deployments typically look

For Tenable-centric use cases, a private deployment usually sits between your Postman collections and Tenable WAS:

1. Your CI/CD or internal tooling calls your private FroggerAPI endpoint to convert Postman to OpenAPI.
2. The generated spec is stored in your own artifact store or version control.
3. Tenable WAS pulls or is fed the latest spec from your trusted storage.

In this model, both the Postman collections and the OpenAPI specs stay inside your environment; only Tenable and your own systems see them.

Where Pro / governance features run on-prem

The same Pro features described on the main site can be deployed privately:

• Spec history & diffing – store versioned OpenAPI specs in your own database or S3 bucket and expose diff results via the private API.
• Rules engine & policy checks – run the linting engine inside your VPC, with optional organization-specific rule packs.
• Tenant-aware workspaces & API keys – manage tenants and keys in your own identity / secret systems if preferred.

In practice, an “Enterprise / on-prem” deployment is usually the Pro feature set (history, diffing, rules) deployed entirely inside your environment, with licensing structured around tenants or environments rather than per-call usage.

Network & security controls

Where and how you expose the API is up to you. Common choices include:

• Internal-only hostname reachable from CI/CD and Tenable but not from the public internet.
• mTLS between your internal tools and FroggerAPI if you already enforce client certs.
• Integration with your existing WAF, API gateway, or service mesh for rate limiting and auth.

Operational considerations

For on-prem / private deployments, you’ll want to think about:

• Monitoring — metrics and logs shipped into your existing observability stack.
• Upgrades — rolling deployments when a new FroggerAPI version is available.
• Backups — for any databases used to store history, rules, or configuration.

Getting started with a private deployment

Private / on-prem deployments are handled as part of the Enterprise offering. If you’re interested in running FroggerAPI privately, email feedback@froggerapi.io with a short note about:

• Your environment (AWS, on-prem, hybrid).
• Rough scale (collections per day, file sizes, Tenable scan cadence).
• Whether you’re already using Tenable WAS or planning to adopt it.

We’ll follow up with more detailed deployment docs, licensing options, and a technical conversation about your use case.