Available from v0.6.0-beta.3 · Updated 21 October 2026

Applications

Run websites, APIs and bots next to your game servers, deployed from GitHub with logs, saved data, domains and databases.

What you can host

• Websites and HTTP apps in Python or Node.js, and static websites.
• Bots and background workers, for example a Discord bot.
• Your own Docker images, built from your repository's Dockerfile or pulled by digest (Growth and Scale).

Applications share the node's memory, CPU and ports with your game servers. Each application runs in its own locked-down container, with its code read-only.

Create an application

An administrator creates applications from Applications in the panel and assigns each one to an owner. You'll choose:

• Name, owner and node.
• Runtime: Python, Node.js or static website.
• Type: a website (HTTP) or a background bot.
• Source: the GitHub repository as owner/repository, and the full 40-character commit to deploy.
• Command as a list, for example ["node", "app.js"].
• Ports and limits: a free port on the node, the port your app listens on (also given to it as PORT), memory and CPU.
• Environment variables as JSON, for API keys and settings. They're stored encrypted. Never commit secrets to your repository.

A website is ready when its health path, / by default, answers with status 200. A bot is ready when it keeps running.

Deploy, roll back and recover

On the application's page, choose an operation, type the application's name to confirm, and click Queue operation. Refresh the page to see the result.

• Deploy commit runs a new commit. If it fails its health check, the previous release is restored automatically.
• Roll back switches to a release you deployed before. Rollback restores code and settings, not data in databases or volumes.
• Start and Stop the running release.
• Permanently remove inactive release. Up to 10 releases are kept, and new deploys stop at that limit until you remove an old one.
• Recover unconfirmed operation if the node didn't confirm a result, for example after a network drop. It finishes or undoes that same operation safely.

Deploys briefly stop the old release while the new one starts on the same port, so expect a few seconds of downtime.

Logs and recent output

Every operation keeps a deployment log under Deployment history: downloading the source, starting the release and the health check. If a new release fails, the log also shows its last lines of output, which usually explain why.

Recent output shows the last 200 lines your running app printed. Click Show recent output, and Refresh to update it. In both logs, the values of your application's environment variables are hidden as •••• (values of four characters or more).

Data volumes

Your app's code is read-only, and /tmp is cleared on restart. To keep files such as uploads or a SQLite database, use a data volume: a named folder mounted into the app, for example at /data.

• An administrator adds volumes, up to eight per application, with a lowercase name and an absolute path outside /app, /tmp and system folders.
• A new volume is attached at the next deploy or rollback, or when you stop and start the app.
• Volumes stay attached across deploys and rollbacks. Their files are never rolled back with your code.
• To delete a volume and its data, stop the application first, then use Delete volume and data.
• Volumes have no size limit of their own, so watch the node's free disk space and back up important data.

App addresses

Websites on the panel's own server get a free address such as https://shop.example.com, with HTTPS from Let's Encrypt. Your existing web server serves them; no second IP address is needed.

1. As the installation owner, open Applications and check the App domain. It defaults to the panel's hostname without its first part: a panel at panel.example.com gives example.com.
2. At your DNS provider, add one record: *.example.com, type A, pointing at your server's public IP. On Cloudflare, set it to DNS only (grey cloud); proxied records can't get certificates. The Applications page shows when the record is found.
3. On an application's page, the owner or an administrator types its Address, for example shop, and saves. HTTPS is ready in about a minute.

Addresses are one word (letters, numbers and hyphens). Names such as www, panel and mail are reserved. A stopped application's address comes back when it runs again. Installations upgraded from beta.5 run sudo nodara-update enable-app-addresses once first.

Custom domains and HTTPS

Websites can use your own domain with automatic HTTPS. On the application's page, claim a hostname such as app.example.com. Then, at your DNS provider:

1. Add the TXT record shown on the page, at _nodara.app.example.com. Keep it afterwards; it proves you own the domain.
2. Point the hostname's A record at the node's edge IP shown on the page.
3. Click Verify DNS and HTTPS. If the certificate is still being issued, wait a few minutes and verify again.

Each website can have up to five domains.

Dockerfiles and prebuilt images

On Growth and Scale, and once your server operator has enabled builds on the node, an application can use:

• Your repository's Dockerfile. Builds run without internet access, so base images must be pinned by digest (FROM name@sha256:…) and already present on the node, and dependencies must be in your repository or the base image.
• A prebuilt image, given as name@sha256:…. Tags like :latest aren't accepted, so you always get exactly the image you chose.

Containers run without root and with the same protections as other applications. Each release keeps its own image until you remove the release.

Private repositories and deploy on push

Private repositories (Growth and Scale). Create a fine-grained GitHub token with access to just that repository and read-only Contents permission, and save it on the application's page. It's stored encrypted, never shown again, and used only to download the commit being deployed.

Deploy on push. Click Enable deploy on push, then in your GitHub repository go to Settings → Webhooks → Add webhook:

• Payload URL: the URL shown on the page.
• Content type: application/json.
• Secret: the secret shown on the page. It's shown only once.
• Events: just the push event.

Each push to your chosen branch deploys automatically. Other branches and unsigned requests are ignored. Every push creates a release, so remove old ones to stay under 10.

Databases

On Growth and Scale, when the node has a managed database host, each application can have one MySQL database:

1. Create the database on the application's page.
2. Deploy. Your app receives DATABASE_URL plus DATABASE_HOST, DATABASE_PORT, DATABASE_NAME, DATABASE_USER, DATABASE_PASSWORD and DATABASE_TLS.

Rotating the password redeploys your app automatically. Releases deployed before a rotation can't connect if you roll back to them. Deleting the database removes its data permanently.

For server operators

Application hosting needs a little setup on each Docker node before customers can use it:

• Runtime images: from v0.6.0-beta.4, Nodara uses reviewed Python and Node.js images pinned by digest, and downloads each one the first time an application needs it. Nothing to configure, for new and upgraded installations alike. To use a different reviewed image, set NODARA_APP_IMAGE_PYTHON, NODARA_APP_IMAGE_NODE or NODARA_APP_IMAGE_STATIC in the agent's environment. Data volumes also use these images.
• Custom domains: a separate Caddy instance dedicated to applications, with ports 80 and 443, and the node's application edge IP set in the panel.
• Builds and prebuilt images: off until you set NODARA_APP_BUILDS=1 on the agent. Optional limits: NODARA_APP_BUILD_CPUS (default 2), NODARA_APP_BUILD_MEMORY_MIB (default 2048) and NODARA_APP_BUILD_SECONDS (default 900). Pre-pull the base images your customers' Dockerfiles use.
• Databases: configure the node's managed database host, the same one game-server databases use.

Containers can make outbound connections, and Docker isolation isn't a virtual-machine boundary. Only host code from people you trust, or add an outbound network policy on the node. Builds and images have no disk quota, so watch disk usage.