Routeros App Yaml logo

Routeros App Yaml

Organization
tikoci
routeros-app-yaml

RouterOS /app YAML format for container applications (7.21+ builtin app, 7.22+ custom YAML creation). Use when: writing or validating RouterOS /app YAML files, working with MikroTik container apps, building docker-compose-like definitions for RouterOS, creating /app store schemas, debugging /app validation errors, or when the user mentions /app, tikapp, or RouterOS container YAML.

Overview

Publishertikoci
Repositoryrouteros-skills
Skill namerouteros-app-yaml
Stars
85
Forks
18
Bundled files
1
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 1 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by tikoci on GitHub. Read the source before you install it.

Installation

Install the Routeros App Yaml AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/tikoci/routeros-skills/tree/main/routeros-app-yaml
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/tikoci/routeros-skills.git /tmp/routeros-skills
mkdir -p .claude/skills
cp -r /tmp/routeros-skills/routeros-app-yaml .claude/skills/routeros-app-yaml
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Routeros App Yaml in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Routeros App Yaml on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Routeros App Yaml is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

RouterOS /app YAML Format (7.21+)

RouterOS 7.21 introduced the /app path (built-in app listing and management). The full YAML app creation feature (/app/add) appeared in 7.22 (first seen in 7.22beta5). Think of it as MikroTik's opinionated alternative to docker-compose — but it is NOT docker-compose, with significant differences.

What /app Is

The /app subsystem lets users define one or more containers as a single "application" in YAML. RouterOS parses the YAML, creates containers, volumes, networks, and config files, then manages the lifecycle.

Key concepts:

  • Each /app is defined by a YAML document with services, configs, volumes, and networks
  • The YAML is loaded into RouterOS via CLI (/app/add yaml-url=...) or REST API
  • Built-in apps ship with RouterOS (visible at GET /rest/app)
  • Custom apps can be added from URLs or inline YAML
  • App stores (app-store-urls=) provide curated collections

Critical Differences from docker-compose

Featuredocker-composeRouterOS /app
Port formathost:container[/protocol]Two styles (see below)
EnvironmentKEY=value or listSame, but placeholders expand
VolumesNamed or bind mountsSubset — no bind mount options
NetworksFull docker network modelSimplified — name + external
BuildFull Dockerfile supportMinimal (context + dockerfile)
ConfigsDocker configs APIInline content only
Deploy/resourcesYesNo — not supported
Top-level version:Deprecated (was required)Not used
File extension.yml / .yaml.tikapp.yaml (convention)

Top-Level Properties

PropertyTypeRequiredDescription
namestringNoUnique identifier for the /app
descrstringNoHuman-readable description shown in app UI
pagestring (URI)NoProject homepage URL
categorystring (enum)NoApp store classification
iconstring (URI)NoIcon URL (shown in WebFig with show-in-webfig=yes)
default-credentialsstring or nullNousername:password shown in UI
url-pathstringNoURL path suffix for browser access (e.g., /admin)
credentialsstringNoCredential hint (alternative to default-credentials)
optionbooleanNoWhether app is optional
auto-updatebooleanNoPull and restart containers on every boot
servicesobjectYesContainer service definitions (≥1 required)
volumesobjectNoNamed volume declarations
networksobjectNoNetwork declarations
configsobjectNoConfig file declarations with inline content

Category Values (Exhaustive)

text
productivity, storage, networking, development, communication,
file-management, search, video, media, media-management,
home-automation, monitoring, database, automation, ai,
messaging, radio, security, business

New categories appear when MikroTik adds built-in apps. The CI schema validation catches these.

Service Properties

Each key under services: defines one container. Required property: image.

PropertyTypeDescription
imagestringContainer image (omit registry to use /container/config's registry-url)
container_namestringExplicit name; used as base for file paths under /container
hostnamestringContainer hostname
entrypointstring or string[]Override default entrypoint
commandstring or string[]Override default command
portsarrayPort mappings (see format section)
environmentobject or array or nullEnvironment variables (KEY=value list or {KEY: value} map)
volumesarray of stringsVolume mounts (e.g., my-vol:/data)
configsarray of objectsConfig file placements ({source, target, mode})
restartenumno, always, on-failure, unless-stopped
depends_onarray or objectService dependency ordering
devicesarray of stringsDevice mappings passed to container
userstringUser to run container as
security_optarray of stringsSecurity options
shm_sizestringShared memory size
stop_grace_periodstring or intTime before SIGKILL
ulimitsobjectResource limits (e.g., nofile: {soft: 65536, hard: 65536})
buildobject or stringBuild configuration (context, dockerfile, args)
healthcheckobjectHealth check (test, interval, timeout, retries, start_period)
stdin_openbooleanKeep stdin open
exposearrayInternal ports (not published to host)
secretsarray of stringsSecrets to expose
attachbooleanAttach to stdio

Port Format — Two Styles

RouterOS supports two port mapping string formats. Both are valid; new apps from 7.23beta2+ prefer the colon style.

Old OCI-style (pre-7.23)

text
[ip:]host_port:container_port[/tcp|/udp][:label]

Examples:

yaml
ports:
  - "8080:80/tcp"
  - "8443:443/tcp:https"
  - "192.168.1.1:53:53/udp:dns"

New RouterOS style (7.23+)

text
[ip:]host_port:container_port[:label][:tcp|:udp]

Protocol is appended with colon instead of slash:

yaml
ports:
  - "8080:80:web:tcp"
  - "8443:443:https:tcp"
  - "53:53:dns:udp"

Long-form (object) syntax

yaml
ports:
  - target: 80
    published: 8080
    protocol: tcp
    name: web
    app_protocol: http

IP Addresses and Placeholders in Ports

Port strings can include literal IPs or placeholder expressions:

yaml
ports:
  - "[accessIP]:[accessPort]:80/tcp:web"      # Old style with placeholders
  - "[accessIP]:[accessPort]:80:web:tcp"       # New style with placeholders

Placeholders

RouterOS expands these placeholders at deploy time:

PlaceholderExpands to
[accessIP]IP address for accessing the app from outside
[accessPort]Primary host port for external access
[accessPort2]Secondary host port
[containerIP]IP address assigned to the container
[routerIP]Router's own IP address

Placeholders appear in port mappings, environment values, and config content.

Configs (Inline Files)

Top-level configs: declares config content; services reference them:

yaml
configs:
  my-config:
    content: |
      server {
        listen 80;
        server_name [accessIP];
      }

services:
  web:
    image: nginx:alpine
    configs:
      - source: my-config
        target: /etc/nginx/conf.d/default.conf
        mode: 0644

Volumes and Networks

yaml
volumes:
  app-data: {}      # Named volume (null or empty object)

networks:
  app-net:
    name: my-network
    external: true   # Use existing RouterOS network

Store Schema (app-store-urls)

RouterOS can load app collections from URLs configured via app-store-urls=. The store format is simply a YAML array of /app definitions:

yaml
- name: app-one
  services:
    web:
      image: nginx:alpine
- name: app-two
  services:
    db:
      image: postgres:16

Store files use the .tikappstore.yaml extension by convention.

REST API for /app

typescript
// List all /app entries (built-in + custom)
const apps = await fetch(`${base}/app`, auth).then(r => r.json());

// Each entry has: .id, name, yaml (raw YAML string), and metadata
// The 'yaml' field is a RouterOS string containing the full YAML document

// Add a custom /app from URL
await fetch(`${base}/app`, {
  method: "PUT",
  ...auth,
  body: JSON.stringify({ "yaml-url": "https://example.com/my-app.tikapp.yaml" }),
});

Note: The /app endpoint requires the container extra package to be installed.

JSON Schema for Validation

Two schema variants exist for each /app document:

SchemaPurposePort validationEnv var names
*.latest.jsonCI/strict validationRegex patterns enforced^[A-Z_][A-Z0-9_]*$ only
*.editor.jsonEditor/SchemaStore UXNo regex (allows autocompletion)Case-insensitive

The strict schema has regex pattern on port strings which prevents VSCode autocompletion — the YAML extension won't suggest values for fields with patterns. The editor variant removes these patterns.

VSCode Integration

Add to VSCode settings for YAML autocompletion:

json
{
  "yaml.schemas": {
    "https://tikoci.github.io/restraml/routeros-app-yaml-schema.latest.json": "*.tikapp.yaml",
    "https://tikoci.github.io/restraml/routeros-app-yaml-store-schema.latest.json": "*.tikappstore.yaml"
  }
}

Use .editor.json URLs for better autocompletion at the cost of less strict validation.

Version History

  • 7.22: Initial /app support with basic service properties
  • 7.23beta2: New colon-style port format (:tcp/:udp suffix)
  • 7.23+: Additional service properties (devices, expose, secrets, attach)

Common Mistakes

  • Assuming docker-compose compatibility — not all properties are supported, some behave differently
  • Using version: key — RouterOS ignores it; not needed
  • Mixing port format styles in a single entry — each port string must use ONE style exclusively
  • Uppercase env var names required in strict validation — use *.editor.json for mixed case
  • Forgetting the container package — /app returns 404 without the container extra package
  • Using deploy: or resources: — not supported by RouterOS

Additional Resources

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Routeros App Yaml AI skill do?

RouterOS /app YAML format for container applications (7.21+ builtin app, 7.22+ custom YAML creation). Use when: writing or validating RouterOS /app YAML files, working with MikroTik container apps, building docker-compose-like definitions for RouterOS, creating /app store schemas, debugging /app validation errors, or when the user mentions /app, tikapp, or RouterOS container YAML.

Why use Routeros App Yaml on TypingMind?

Because you install it once and use it with any model. Routeros App Yaml is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Routeros App Yaml in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/tikoci/routeros-skills/tree/main/routeros-app-yaml. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Routeros App Yaml?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Routeros App Yaml?

As many as you like. As long as a model supports skills, you can use Routeros App Yaml with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Routeros App Yaml AI skill free?

Yes. It is published on GitHub by tikoci under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇