Containerized App management

Summary

Sub-menu: /app
Packages required: container

The App menu provides a catalog of applications that can be deployed in a couple of clicks. Each app can consist of one or multiple pre-configured containers and the necessary RouterOS configuration such as firewall rules and address translation will be applied automatically. This catalog is prepared and maintened by MikroTik, but the container images get sourced from multiple registries such as Docker Hub, GCR and Quay.

The configuration parameters, however, can be edited before enabling an app, and the applied yaml file can always be viewed.

Requirements

The App system inherits the same requirements as the Container package:

• Architecture Support: arm64, and x86 architectures
• Container Package: Must be installed
• Device Mode: Container mode must be enabled (requires physical access and device reset)
• External Storage: Highly recommended for optimal performance
• Memory Requirements: Adequate RAM for container operations (16MB SPI flash devices may require external storage for images)
• Architecture Limitations: Devices with EN7562CT CPU (like hEX Refresh) are not supported

Security Considerations

As with the underlying Container system, the App menu inherits security implications:

• Physical access required to initially enable container support
• Once enabled, containers can be managed remotely
• Compromised devices can use containers to install malicious software
• Device security is equivalent to the security of running containers
• Third-party container images may introduce security vulnerabilities

Setup Wizard

The App menu includes a setup wizard (button "Setup" in the GUI, or command /app setup). This wizard automates all the networking, storage, and registry setup that would otherwise require multiple manual steps.

Step 1: Storage Selection

Choose the storage disk for application installation. The system automatically detects available formatted disks (nvme1, usb1, disk1, etc.). If no suitable disk appears, it must be formatted with ext4 or btrfs and mounted via /disk menu.

Requirements:

• Minimum 100MB/s sequential read/write speed and 10K random IOPS recommended
• Use /disk/test command to verify storage performance
• External storage highly recommended for optimal performance

Step 2: Bridge Configuration

Select the LAN bridge interface for container networking. This enables automatic port forwarding and application autodiscovery on the local network. The wizard automatically configures:

• Virtual ethernet (veth) interfaces
• Adding the veth interface to the configured bridge
• NAT rules for outbound connectivity

Step 3: IP Configuration

Specify the router IP address for application access. The system auto-detects the primary IP but allows manual override for complex network configurations. This IP will be used for:

• Application UI-URL generation
• Automatic port forwarding rules
• WebFig integration links

Completion

After completing the setup wizard, the App system is ready for immediate use. Applications can be enabled directly through the interface and will automatically handle all underlying container configuration.

Configuration

App configuration is accessible through /app/settings and provides simplified setup compared to manual Container configuration:

Storage Configuration

• disk: Storage device for application installation (auto-detected - could be nvme1, usb1, disk1, etc.)
• Performance Requirements: Minimum 100MB/s sequential read/write speed and 10K random IOPS recommended
• Filesystem Support: ext4 or btrfs filesystem required, formatted and mounted
• Performance Testing: Use /disk/test command to verify storage performance

Network Configuration

• router-ip: Network IP address for RouterOS device (auto-detected, can be overridden)
• assumed-lan-bridge: Network bridge interface for LAN connectivity (auto-configured)
• Port Forwarding: Automatically configured for application web interfaces

Registry and Updates

• registry-mirrors: Container registry mirror configuration (defaults to Docker Hub)
• auto-update: Automatic application updates (yes/no)

Storage Paths

• assumed-media-path: Default media storage path (typically raid1/media or disk1/media)
• assumed-download-path: Download directory path (typically raid1/media/downloads)

User Interface

• show-in-webfig: Display application access buttons in RouterOS WebFig interface

Application Management

Applications are managed through the /app interface, providing status monitoring and lifecycle control similar to the underlying /container system:

/app> print 
Flags: X - DISABLED, R - RUNNING
Columns: NAME, UI-URL, MEMORY-CURRENT, APP-SIZE, DATA-SIZE, CATEGORY, DESCRIPTION

Status Indicators and Metadata

• Flags:
  • X (DISABLED) - Can indicate two states: not downloaded/installed (APP-SIZE and DATA-SIZE will be empty), or downloaded but disabled (APP-SIZE and DATA-SIZE show storage usage)
  • R (RUNNING) - Application actively running and accessible
• UI-URL: Direct web interface access URL when application is running
• MEMORY-CURRENT: Real-time memory consumption in MiB (only when running)
• APP-SIZE: Container image storage consumption in MiB (shows space used when downloaded)
• DATA-SIZE: Application persistent data size in KiB/MiB (shows configuration and user data)
• CATEGORY: Application functional classification
• DESCRIPTION: Application functionality description

Application Lifecycle Management

Deployment Process

Unlike manual Container deployment which requires multiple configuration steps (veth interfaces, bridge setup, environment variables, mounts, and firewall rules), App deployment automates the entire process:

1. Selection: Choose application from catalog via CLI or WebFig
2. Download: Automatic container image download and extraction
3. Network Setup: Automatic veth interface and bridge configuration
4. Port Forwarding: Automatic firewall rule creation for web access
5. Startup: Container initialization with pre-configured settings
6. Access: UI-URL becomes available for immediate web interface access

Cleanup Command

The cleanup command provides complete application removal, including all associated data. This operation is destructive and irreversible:

/app> cleanup pihole 
App data will be lost, continue? [y/N]:

Cleanup Process:

1. Stops the running container
2. Removes all application data and configuration files
3. Deletes container image from storage
4. Resets application to uninstalled state (empty APP-SIZE and DATA-SIZE)
5. Removes network configuration specific to the application

Warning: All user data, configuration settings, and application state will be permanently lost. The application will return to its original catalog state and require complete reconfiguration if reinstalled.

Available Applications by Category

Tips and Best Practices

• Storage: Use external storage (USB/SATA/NVMe) for better performance and capacity
• Memory: Monitor application memory usage through /app print
• Updates: Enable auto-update for security and feature updates
• Networking: Applications automatically handle port forwarding and URL generation
• Data Persistence: Application data is stored in configured storage paths and survives application restarts