One-click apps and scripts
A one-click app is software we install for you right after your server boots — n8n, for example, or whatever else is in the catalog when you deploy. You pick it while you deploy, fill in a couple of fields, and the install runs by itself. You can watch it, and when it's done the app's address and login are waiting on the server's Apps tab.
There's no extra charge. You pay for the server as usual; the software is open source, or uses a licence you bring yourself.
What's in the catalog
Each app shows its licence on its tile:
| Label | What it means |
|---|---|
| Open source | An open-source licence (MIT, Apache, GPL, AGPL…). Free to use. |
| Source available | Free to self-host, with the vendor's own terms on top — n8n's fair-code licence, for example, lets you use it for your business but not resell it as a hosted service. Read the licence before you build a product on it. |
| Bring your own licence | Commercial software, such as a hosting control panel. We install it; the licence comes from the vendor. Ekire doesn't sell or charge for these licences. |
An app is only offered in regions where the operating system it needs is available. If a tile says Not in this region, pick another region.
Deploy a server with an app
Pick Region, then switch Step 2 to One-click app
Choose an app. We pick a compatible operating system for you (you can change it if the app supports more than one) and raise the size to the app's minimum if your choice is too small.
Fill in the app's fields
Most apps ask for an admin email and, optionally, a domain (point it at the server as soon as you've deployed; see Your own domain). Some ask for a licence key or an API key. The admin password is generated for you — you'll reveal it once the install finishes, so nobody can open the app first and claim it.
Deploy and watch it install
You land on the server's Apps tab. The install starts as soon as the server has booted and shows a progress bar and a live log. Most apps take 3–15 minutes; control panels can take up to two hours.
Your own domain (optional)
You don't need a domain. By default the app is on your server's IP — http://<server IP> — as soon as it's
installed. (A few apps that shouldn't be public without HTTPS, such as the OpenClaw agent, stay private until
you give them a domain; their notes say how to reach them meanwhile.)
A domain needs an A record pointing at the server's IP, and nothing else: remove any other A record and any AAAA record for that name (Ekire servers are IPv4-only, and Let's Encrypt checks IPv6 first, so a leftover AAAA record stops the certificate). If your DNS provider proxies records (Cloudflare's orange cloud), set this one to DNS only. A new server gets its IP the moment you click Deploy — it's at the top of the server's page before the server has even booted — and a server you already have shows it there too. To put an app on your own domain with HTTPS, do it either way:
- While you install it. Enter the domain in the app's Domain field and add the A record right away. The install looks the domain up when it sets up the web server (for a control panel, when it sets the server's hostname): for most apps that's a few minutes after the server boots, but wg-easy and the control panels do it among their first steps. If the domain points at your server by then, the app gets a free HTTPS certificate straight away. If it doesn't yet, the app starts on the IP, and you switch later as below. On a server you already have, point the domain first and then install.
- Any time after. On the server's Apps tab, click Use your own domain on the app. Add an A record for the domain pointing at the server's IP (the dialog shows it), click Check, then Switch to this domain. Check only turns green when the domain points at this server and nowhere else. Ekire moves the app to HTTPS on that domain and updates the app's own address — its links, sign-in and webhooks — while its data, users and passwords stay as they are. The switch shows Switching with its progress and log on the Apps tab, waits a few minutes for the certificate, and you can move to another domain later the same way. If the domain stops pointing here before the switch moves anything, the switch stops and nothing changes; it never moves the app back to the IP.
The button shows on the most recent install of each app, while the server is running. Apps whose recipe has no domain switch don't show it: control panels and platforms that manage domains themselves (HestiaCP, Plesk, DirectAdmin, cPanel, Coolify), where you add domains in their own settings, and the Docker app, which serves nothing by itself. After a rebuild, earlier installs no longer show it (the app is gone).
Without a domain, or with one that didn't point only at the server when the install checked it, an app is
served over plain HTTP on http://<server IP>, and the Apps tab says why. Once the domain points here,
use Use your own domain. (For an app without the button that uses Caddy, you can move the web server by
hand: put the domain in place of :80 on the first line of the app's file in /etc/caddy/sites.d/ and run
systemctl reload caddy. That moves only the web server, not the app's own address settings.) A few apps
that shouldn't be public without HTTPS (such as the OpenClaw agent) stay private without a domain instead,
and their notes say how to reach them.
Ports
Most apps — n8n, WordPress, Nextcloud and the other self-contained web apps — sit behind a small web server (Caddy) on ports 80 and 443. Their own ports listen only inside the server. Some apps open more ports to the internet:
| App | Opens beyond 80 and 443 |
|---|---|
| Gitea | TCP 2222 for Git over SSH, unless you turn that option off when you install. |
| wg-easy | UDP 51820, the VPN itself. |
| Coolify | TCP 8000 (the dashboard), 6001 and 6002 (its live updates and terminal). Coolify runs its own proxy on 80 and 443, not Caddy, for the apps you deploy with it. |
| HestiaCP, Plesk, DirectAdmin, cPanel & WHM | The panel's own ports (HestiaCP 8083; Plesk 8443 and 8880; DirectAdmin 2222; cPanel 2087, 2083, 2096 and 2080), plus FTP (21), mail (25, 465, 587, 110, 995, 143, 993) and DNS (53, TCP and UDP). Panels run their own web server instead of Caddy. |
OpenClaw opens 80 and 443 only when you give it a domain, and the Docker app opens nothing by itself.
When you pick an app, on the deploy page or in Install an app, Ports it opens lists every port it
makes reachable. If the server's firewall is on, add an Accept rule for each of them, because anything
without one is blocked. Gitea's 2222 and wg-easy's 51820 are opened by Docker, which skips the server's own
ufw rules; the firewall you set in the Ekire console still applies to them. Gitea's notes say how to close
2222 if you no longer want Git over SSH.
When the app uses Caddy
Before downloading anything, the install checks that the web server can take over: it stops early if
another program already uses ports 80/443, if you run your own Caddy setup on the server (Ekire won't change
it), if your Caddy setup uses environment placeholders (Ekire can't check what it will load), or if another
site on the server — another app's or your own — already answers on the same address. Two apps without a
domain can't share one server's IP, so give the second one its own domain. If your own Caddy setup has a site
that answers HTTPS for every host (an https:// or :443 site, or on-demand TLS), an app without a domain
is refused too: its plain-HTTP site on the IP would take over that site's redirect to HTTPS. Give the app a
domain, or turn those redirects off in your Caddyfile (auto_https disable_redirects, or auto_https off). The new site is checked before
the web server loads it, so a problem never takes your other sites offline. Once it's loaded, the install
checks that requests for the app's address reach this app's site rather than another site on the server (a
new HTTPS address that's still waiting for its certificate can't be checked yet).
The Apps tab
Every server has an Apps tab. For each install it shows:
- Status — Waiting for the server, Installing with progress, then Installed, Failed or Cancelled. A domain switch shows Switching and Switched instead, as its own entry under the app.
- The log — what the installer printed, with the values you typed, the passwords we generated and any credentials it reported masked out. A script's log, results and failure reason are shown to the account owner only (not to team collaborators, reseller operators, read-only API keys or Ekire staff).
- The results — the app's address, the admin username, and any notes.
- Credentials — hidden until you click Reveal credentials. Every reveal is recorded in Ekire's audit log.
Stop install stops an install that's still running. Once the install has reached the server, it shows Stopping until the server confirms the installer has stopped, then Cancelled. Until then the server still counts as busy, so you can't start another install or a retry on it, and two installers never run side by side. If the installer had already finished when you pressed it, nothing is undone: the install keeps its result, its address and its credentials.
When an install succeeds, everything the installer reported (the address, usernames and any credentials it
created) is also saved on the server, readable only by root, in /root/ekire-apps/<app>.txt. A domain
switch updates only the address lines in that file and keeps everything else. Whether the admin password is
in that file depends on the app:
- In the file, in plain text: the admin password of Coolify, Flowise, Langflow, Plesk and DirectAdmin, and OpenClaw's gateway token (anyone who has it controls the whole server).
- Not in the file: the admin password we generate for any other app. Reveal it on the Apps tab.
Before you make an image or snapshot of the server to share, or give someone else root on it, delete that file (keep a copy off the server if you need one) and change any password in it that you still use.
If an install fails
The tab shows why — a failing step, an unsupported OS, an app that didn't come up in time. Retry runs the same install again (with a fresh admin password). Only the most recent install on a server can be retried, and not while another one is running. The server is billed as usual whether or not the app installed; destroy it if you don't want to keep it, or rebuild it to start clean.
When the cause is something you entered (a licence key the vendor refused, an admin email on a domain that doesn't exist, a username the app won't take), the reason says what to fix. Retry reuses the values you typed, so it helps when the fix is outside Ekire, such as allowing the server's IP for your licence in the vendor's client area. To use different values, install the app again from Install an app, or deploy a new server for an app that needs one.
A domain switch that fails has no Retry: start it again from Use your own domain. Its reason says whether anything moved. If a switch is stopped part-way, fails after it started, or its results can't be read back, the app's own entry says so, because the app may already answer on the new domain; running the switch again finishes it and refreshes the address.
Rebuilding or destroying a server stops anything that was installing on it.
Install an app on a server you already have
Open the server, go to Apps, and click Install an app. Only apps that are safe to add to a running server are listed — self-contained apps such as n8n. Control panels and hosting platforms take over the whole server, so they're offered only when you deploy a new one.
The app installs alongside whatever is already there. Take a snapshot first if the server matters to you.
A few limits apply:
- The server must be running Linux, be switched on, and have finished booting.
- One install at a time per server, and up to five running installs across your account.
- The server must meet the app's minimum size — resize it first if it doesn't.
Scripts
Scripts (in the sidebar) are your own setup scripts: the commands you run on every new server. Save one, then either pick it on the deploy page under Run a script after boot, or open a running server and use Apps → Run a script.
- Scripts are bash and run once, as root, after the server boots. The first command that fails stops the script.
- Each script can be up to 32 KB.
- You can use the same helpers the app installers use:
ekire_progress 50 "message"moves the progress bar,ekire_output key "value"shows a value on the Apps tab, andekire_fail "reason"stops with a message you'll see. - The output appears on the server's Apps tab, like an app install.
Scripts often hold secrets, so they're yours alone: team collaborators and reseller operators can't see or run them.
Teams and resellers
- Team collaborators can watch installs and read app logs, but can't install apps, switch an app's domain, reveal credentials or run scripts — those stay with the account owner. A script's output stays hidden from them.
- Reseller operators working in a customer's account can deploy servers with apps, install apps on running servers, switch an app to the customer's domain, and retry, stop or reveal the credentials of app installs, because they run those servers. They can't use the customer's saved scripts — and on a script that's running or has run, they see only its status: not its output, and they can't stop, retry or reveal it.
- Ekire staff see app install logs when helping you, but never a script's output.
- Read-only API keys can list installs, but see a script's status only — and can't read your saved scripts.