Skip to main content

Route Templates

What are route templates?​

In a typical Otoroshi deployment, many routes share the same foundational configuration: the same authentication plugin, the same rate-limiting policy, the same CORS headers, the same logging setup. Without a mechanism to capture those shared defaults, every new route must be configured from scratch, which is both tedious and error-prone. Route templates solve this problem by letting you define reusable, preconfigured route blueprints that serve as starting points when creating new routes.

A route template is essentially a pre-filled route configuration. It contains a complete route definition -- frontend, backend, plugins, and all associated settings -- but it is not a live route. A template does not match any domain, does not serve traffic, and does not appear in the proxy engine's routing table. Think of it as a blueprint: when you create a new route from a template, Otoroshi copies the template's configuration into a real route that you can then customize for the specific service you are exposing.

The philosophy: convention over configuration​

Route templates embody the principle of convention over configuration. Instead of requiring every team to remember (and correctly apply) the full set of organizational standards each time they create a route, you define those standards once inside a template. Teams then only need to override what is specific to their service -- typically the target hostname and the frontend domain -- while everything else is inherited from the template.

This approach has several practical benefits:

  • Enforcing organizational standards -- Every new route automatically starts with the plugins and policies your platform team has approved (rate limiting, logging, authentication, CORS, and so on). There is no risk of forgetting a critical security plugin.
  • Speeding up service onboarding -- New teams or new microservices can go from zero to a fully configured, production-ready route in seconds rather than minutes.
  • Reducing configuration drift -- Because all routes originate from a known-good template, the overall configuration across your fleet stays consistent and auditable.
  • Supporting environment-specific defaults -- You can maintain separate templates for development, staging, and production, each with the appropriate backend targets, timeout values, and observability settings.

How templates differ from routes​

It is important to understand that a template and a route are distinct entities, even though a template contains a full route definition internally. A route is an active proxy rule that Otoroshi evaluates on every incoming request. A template is an inert configuration object stored alongside your other entities. Creating, updating, or deleting a template has no effect on live traffic. The template only comes into play at route-creation time, when its embedded route definition is used to pre-populate the new route's fields.

UI page​

You can find all route templates here

Properties​

PropertyTypeDescription
idstringUnique identifier of the route template
namestringDisplay name of the template
descriptionstringDescription of what this template provides
tagsarray of stringTags for categorization
metadataobjectKey/value metadata
routeobjectA full route definition used as the template content

The route property contains a complete NgRoute definition including frontend, backend, and plugins configuration. When a new route is created from this template, the route definition is used as the initial configuration that can then be customized.

Default template​

Otoroshi can have a global default route template configured in the Global Config (under templates.routeTemplate). When set, all new routes will be initialized from this template unless another template is explicitly selected.

JSON example​

{
"id": "route-template_secured_api",
"name": "Secured API template",
"description": "Template for secured API routes with API key authentication and rate limiting",
"tags": ["security", "api"],
"metadata": {
"team": "platform"
},
"route": {
"id": "tpl-route",
"name": "Template route",
"description": "A secured route template",
"tags": [],
"metadata": {},
"enabled": true,
"debug_flow": false,
"capture": false,
"export_reporting": false,
"groups": ["default"],
"bound_listeners": [],
"frontend": {
"domains": ["new-api.oto.tools"],
"strip_path": true,
"exact": false,
"headers": {},
"query": {},
"methods": []
},
"backend": {
"targets": [
{
"id": "target_1",
"hostname": "changeme.internal",
"port": 8080,
"tls": false,
"weight": 1
}
],
"root": "/",
"rewrite": false,
"load_balancing": { "type": "RoundRobin" }
},
"plugins": {
"slots": [
{
"plugin": "cp:otoroshi.next.plugins.OverrideHost",
"enabled": true,
"include": [],
"exclude": [],
"config": {}
},
{
"plugin": "cp:otoroshi.next.plugins.ApikeyCalls",
"enabled": true,
"include": [],
"exclude": [],
"config": {}
}
]
}
}
}

Use cases​

  • Standardized security: Create templates that enforce your organization's security policies (authentication, rate limiting, CORS) so all new routes start with the correct configuration
  • Environment-specific defaults: Create templates per environment (dev, staging, production) with appropriate backends, timeouts, and logging levels
  • Team onboarding: Provide ready-made templates so new team members can quickly create properly configured routes
  • Microservice patterns: Define templates for common patterns like BFF (Backend for Frontend), API gateway, or gRPC proxy

Admin API​

GET    /api/route-templates           # List all route templates
POST /api/route-templates # Create a new route template
GET /api/route-templates/:id # Get a route template
PUT /api/route-templates/:id # Update a route template
DELETE /api/route-templates/:id # Delete a route template
PATCH /api/route-templates/:id # Partially update a route template