How do I create and render a configuration template?

Requires Elite

Quick answer

In the Provisioning area, on the Templates tab, use “Add Template” to create a template: Name, Type (Provisioning or Deprovisioning) and the Content with placeholders like {{ hostname }}. The /render endpoint then renders the template server-side with concrete variables into a finished configuration — sandboxed, with no access to the system.

Prerequisites

Provisioning is available from the Elite tier.

Open the “Templates” tab. Choose Provisioning in the left-hand navigation; the Templates tab is pre-selected. The table shows the existing templates with their name and type.

Screenshot pending provisioning-vorlagen-01 Provisioning area with the Templates tab active and the 'Add Template' button

The 'Templates' tab in the Provisioning area.
Create a template. Click “Add Template” and fill in the dialog:
- Name (required) — e.g. “Nginx vHost Standard”.
- Type (required) — Provisioning or Deprovisioning.
- Content — the template itself, with Jinja2 placeholders, e.g.:
  Example content
```
server {
  listen 443 ssl;
  server_name {{ hostname }};
  root /var/www/{{ site }};
}
```
- Description (optional) — what the template is for.
Screenshot pending provisioning-vorlagen-02 'Add Template' dialog with Name, Type, Content with Jinja2 placeholders and Description

A template with Jinja2 placeholders in the 'Content' field.
Save. The template appears in the list and can be rendered via the API immediately (see the API tab). Rendering is an API operation — the web interface is where you maintain templates.

Create a template — POST /api/v1/provisioning/templates (scope write):

curl -X POST https://demo.notory.io/api/v1/provisioning/templates \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Nginx vHost Standard",
    "template_type": "provisioning",
    "content": "server {\n  listen 443 ssl;\n  server_name {{ hostname }};\n  root /var/www/{{ site }};\n}",
    "description": "Standard-vHost für neue Webprojekte"
  }'

{
  "id": "tp_5f6a…",
  "tenant_id": "3d9b0c12-…",
  "name": "Nginx vHost Standard",
  "template_type": "provisioning",
  "content": "server {\n  listen 443 ssl;\n  server_name {{ hostname }};\n  root /var/www/{{ site }};\n}",
  "description": "Standard-vHost für neue Webprojekte",
  "created_at": "2026-07-08T11:20:00Z",
  "updated_at": "2026-07-08T11:20:00Z"
}

Render a template — POST /api/v1/provisioning/templates/{id}/render with concrete variables:

curl -X POST https://demo.notory.io/api/v1/provisioning/templates/tp_5f6a.../render \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{ "variables": { "hostname": "shop.example.com", "site": "shop" } }'

{
  "rendered": "server {\n  listen 443 ssl;\n  server_name shop.example.com;\n  root /var/www/shop;\n}"
}

Possible errors: 400 (“Template error: …” — syntax error in the template), 401, 403 (Provisioning is not in your tier or no write access), 404 (template not found), 422 (validation).

What happens behind the scenes?

Sandboxed rendering: Rendering runs in a sandboxed Jinja2 environment on the server — templates have no access to the file system or internal objects. Faulty templates return 400 with the error message.
No automatic deployment: Notory only renders the configuration; it is not automatically rolled out to target systems. Delivery is handled by your deployment tooling or a workflow.
Tenant isolation & audit: Templates belong to your tenant; creating, changing and deleting them is logged. Rendering is a read operation against the template store.
Type is documentary: Provisioning/Deprovisioning classifies the template for overview and filtering purposes; both types render identically.