Reducto on-premise runs inside infrastructure that you control. Reducto provides the application, Helm chart, and deployment guidance. You control the network boundary, caller authentication, Kubernetes policy, storage policy, telemetry sinks, and access to the deployment.Documentation Index
Fetch the complete documentation index at: https://docs.reducto.ai/llms.txt
Use this file to discover all available pages before exploring further.
Trust boundary
Reducto on-premise is designed for a single customer tenant. It should be deployed behind your private network boundary and called by trusted services inside your environment. Do not expose the Reducto API directly to the public internet or to untrusted browser clients. If users or applications outside your trusted network need access, place Reducto behind your own gateway, identity provider, firewall, and rate limiting controls. In the on-premise model, Reducto does not provide per-end-user authorization inside a single deployment. API keys authenticate access to the deployment, and resources such as jobs, uploaded files, webhook configuration, and usage data belong to the deployment’s tenant. If you need isolation between business units, applications, or users, run separate deployments or enforce that isolation in your gateway before traffic reaches Reducto.Shared responsibility
| Area | Reducto responsibility | Customer responsibility |
|---|---|---|
| Application code | Ship secure application code, fixes, and supported configuration options | Keep the deployment upgraded and apply security releases promptly |
| Network exposure | Document intended network placement and internal endpoints | Keep Reducto APIs, metrics, databases, object storage, and observability UIs private unless intentionally exposed through your controls |
| API authentication | Support bearer token authentication and file-based key rotation | Enable authentication, manage secrets, rotate keys, and restrict who can call the service |
| Caller authorization | Enforce tenant-level access within the Reducto deployment | Enforce per-user or per-application authorization before requests reach Reducto |
| Document input | Process documents and URLs provided by authenticated callers | Ensure callers only submit documents and URLs they are allowed to process |
| URL fetching | Fetch customer-provided document URLs as part of document processing | Control egress, restrict metadata services, and use allowlists or network policy where needed |
| Kubernetes hardening | Provide Helm values and supported runtime guidance | Apply pod security standards, network policies, ingress policy, secret management, and cluster logging policy |
| Observability | Emit metadata-only logs, metrics, traces, and operational endpoints | Route telemetry to approved sinks, set retention, and restrict observability access to operators |
API authentication
Enable file-based API key authentication for production deployments. See Securing Reducto for setup and rotation steps. Use one or more long random bearer tokens stored in a Kubernetes Secret. Treat the token as a deployment-level credential. During rotation, configure both the current key and the new key, migrate clients, then remove the old key. If you operate multiple caller identities, do not rely on Reducto to distinguish those callers inside one on-premise deployment. Put an API gateway, service mesh, or internal service in front of Reducto to authenticate callers, authorize requested workflows, and attach audit context.Network placement
Place Reducto services on private cluster networks. At minimum:- Expose the API only to trusted internal services or through a controlled ingress.
- Keep PostgreSQL, Redis, object storage, and model services private.
- Keep
/metrics,/prometheus, and observability UIs private to monitoring and operations networks. - Block direct internet access to internal admin or scrape endpoints.
- Use Kubernetes NetworkPolicy, cloud security groups, private endpoints, or equivalent controls to restrict east-west and egress traffic.
Document URLs and uploads
Reducto processes documents supplied by authenticated callers. This includes direct uploads,reducto:// file IDs, presigned URLs, customer storage URLs, and internal URLs when your deployment allows access to them.
Because URL fetching is part of the product, your network design decides which internal resources Reducto can reach. Treat document URL submission as a privileged capability. Only trusted services should be able to ask Reducto to fetch URLs.
Recommended controls:
- Prefer direct uploads or tightly scoped presigned URLs when possible.
- Keep presigned URLs short-lived and limited to a single object.
- Block cloud metadata endpoints and other sensitive infrastructure endpoints from worker egress.
- Use egress allowlists for document source domains when your workflows allow it.
- Avoid passing URLs that embed long-lived credentials.
Internal endpoints
Some endpoints are intended for tenant operators and internal automation, not public callers. Examples include job listing, webhook configuration, billing export, metrics, and Prometheus scraping endpoints. In a single-tenant deployment, these endpoints operate at the tenant boundary. They are not a substitute for per-end-user access control. Restrict them to trusted services and operators through your network and gateway policy.Logs, metrics, and traces
Reducto emits application logs to stdout and can send traces, metrics, and logs through OpenTelemetry. See Observability & Monitoring for configuration. Reducto telemetry is metadata-only observability, not a data pipeline. Logs, traces, and metrics should not include document text, OCR output, extracted values, prompts, model responses, API tokens, access keys, secrets, or other customer content. File names and URLs can reveal customer identity and should be redacted or avoided in telemetry. You own the retention period, sink selection, access policy, and export policy for on-premise telemetry. Telemetry may include job IDs, counts, statuses, durations, sanitized error categories, and other debugging metadata. Route it only to systems approved by your organization.Deployment checklist
- Enable API authentication with
auth.secretPath.enabled. - Put Reducto behind a private ingress or internal gateway.
- Document which services are allowed to call Reducto.
- Restrict metrics, Prometheus, HyperDX, PostgreSQL, Redis, object storage, and model endpoints to internal networks.
- Configure egress controls for URL fetching and block metadata services.
- Use Kubernetes Secrets or your secret manager for API keys and provider credentials.
- Configure telemetry retention, routing, and access controls.
- Keep the Helm chart and Reducto image current with security releases.
- Run separate deployments or gateway-level authorization if you need isolation between internal callers.