Dilnaka Cloud brings application hosting, managed databases, domains and DNS, observability, and email hosting into one AWS-backed workspace. Run apps on shared capacity or a dedicated instance, connect domains you already own, and add a standalone mail server when you need email on those domains.
Deploy in minutes. Connect a GitHub repo or push a Docker image and ship your first app.
Get started →Understand when to stay on shared capacity and when a dedicated Custom instance pays off.
Compare →Keep DNS at your current provider, or delegate it for automatic app and mail records.
Connect a domain →Ready-to-run starting points, copied into your own GitHub account on deploy.
Browse templates →Go from sign-in to a running deploy in four steps. Every account starts with a 7-day free trial on shared capacity — no card required.
Sign in with GitHub and start your free trial instantly.
A project groups your apps, databases, and services into one workspace.
Link a GitHub repo that ships a Dockerfile, or point straight at a published Docker image.
Push to ship. Watch build logs, get a public URL, and roll back if needed.
Core concept
This is the choice that shapes how you run on Dilnaka Cloud. Both run your apps as isolated Docker containers — the difference is whether the underlying server is shared with other customers or reserved entirely for you.
Your apps run as isolated containers on shared EC2 capacity. Cheapest way to start, and ideal when you have small or early-stage clients and want predictable monthly cost without paying for a whole server.
A full EC2 server reserved for you alone. Run multiple of your own apps and databases on it with no noisy neighbours. The right move once you have serious or high-potential clients who need guaranteed resources and full isolation.
Any language or framework runs here, because the unit we deploy is a container, not a runtime we have to recognise. Ship a Dockerfile in your repo and Dilnaka builds it on the host. No Dockerfile? Frameworks marked Auto Dockerfile are recognized from the files in your repo — framework config files, manifests like package.json or Gemfile and what they declare — and a matching Dockerfile is generated for you. Your own Dockerfile always wins when both exist.
Caspian
Auto Dockerfile
Rahti
Auto Dockerfile
Prisma PHP
Auto Dockerfile
Next.js
Auto Dockerfile
Laravel
Auto Dockerfile
Django
Auto Dockerfile
Rails
Auto Dockerfile
FastAPI
Auto Dockerfile
Flask
Auto Dockerfile
Go
Auto Dockerfile
Rust
Auto Dockerfile
Node.js
Auto Dockerfile
Static sites
Dockerfile
Connect a repository and every push to the tracked branch builds and redeploys. Pick the branch and root directory, limit which paths trigger a build, or turn auto-deploy off and release each change yourself.
Point at a published image and run it directly — no repository, no build step. Useful for off-the-shelf software and for images your own CI already builds.
A template is a ready-to-run starting point. Deploying one copies the source into your own GitHub account and provisions it, so what you get is your project — not a shared demo.
n8n
Flexible workflow automation for connecting apps, APIs, and AI services. Deploys from the official n8n container image with persistent workflow data.
TypeScript n8n Dedicated only
OpenClaw
Open-source personal AI assistant that really does things — inbox, email, calendar, and more. Deploys from the official container image.
TypeScript OpenClaw Dedicated only
Open WebUI
Private ChatGPT-style interface for OpenAI-compatible APIs. Connect hosted providers without running a local GPU model.
Python Open WebUI Dedicated only
Flowise
Visual builder for AI agents, tools, RAG pipelines, and hosted-model workflows. Includes persistent workflow and credential storage.
TypeScript Flowise Dedicated only
Langflow
Python-oriented visual AI workflow builder for agents, RAG, tools, and model providers, with protected administrator access.
Python Langflow Dedicated only
LiteLLM Proxy
OpenAI-compatible AI gateway for routing requests to multiple hosted model providers through one protected endpoint.
Python LiteLLM Dedicated only
Add a database to a project and it is provisioned with its own credentials, injected into your app's environment, and browsable from the dashboard. Five engines are managed for you.
PostgreSQL
Managed
MySQL
Managed
MariaDB
Managed
Redis
Managed
MongoDB
Managed
Data browser
Browse tables, run SQL, and inspect Redis keys from the project view — no client to install. Queries run as your database's own limited role.
Backups & restore
Take a snapshot on demand or put a database on a schedule with a retention window. A backup includes the database's own disk, and a restore boots an isolated copy so your live database is never overwritten.
Encrypted at rest
Credentials and connection strings are stored with envelope encryption, connections use TLS, and each tenant's database is isolated from its neighbours on the host.
Storage that grows with you
Every new database gets a disk of its own, and any app can get one by switching on persistent storage. Disks grow automatically with no downtime, stop at the maximum you set, and never fill another service's disk. At the limit a database turns read-only instead of crashing. Dedicated servers' main disks grow the same way. Storage is billed at $0.15 per GB of disk per month.
How storage works →dilnaka connect is in progress so
local tools can reach a database without it being exposed to the public internet.
Add a domain you already own once, then reuse it across applications and mail. Domains live at the account level rather than inside one project, so the same domain can keep serving different services as your stack changes. Dilnaka Cloud does not register or sell the domain itself.
External DNS
This is the default. Your registrar or DNS provider stays authoritative, and Dilnaka Cloud gives you the records to add for each app or mail domain. You can verify those records from the dashboard without moving the rest of your zone.
Managed DNS
Choose managed DNS and Dilnaka Cloud creates a Route 53 zone, copies the existing records it can discover, and gives you four nameservers to set at your registrar. After delegation is verified, records for your apps and hosted mail are created automatically.
Add the registered domain, such as example.com.
Subdomains are records beneath it, not separate account domains.
Keep external DNS for manual control, or review the imported-record summary before replacing your registrar's nameservers with the managed set.
Use hostnames under the domain for apps or mail. Managed zones publish the needed records; external zones show the exact records for you to create.
Run email on your own domain: mailboxes, webmail, IMAP and SMTP on a server of your own. Mail hosting is a standalone purchase like a dedicated instance — it needs no plan, and it is separate from app hosting. A mail server runs nothing but mail. Tier prices, mailbox and domain allowances, storage, and sent-message allowances below come from the same live catalog used by the pricing page.
Mail Solo
$29/month
Mail Starter
$39/month
Mail Business
$79/month
A launched server is reachable but idle until your domain points at it. We show you the records to add and then check each one on its own, because they fail independently: MX decides whether the domain can receive, SPF and DKIM decide whether what it sends is accepted, and DMARC is advisory. A domain can receive for days before its sending records propagate, so you are told exactly which one is missing rather than a single pass/fail.
DMARC is strongly recommended but never blocks a working server, and the checks tolerate how a registrar writes a record — a trailing dot, a split TXT value, or different casing is not an error.
Outbound mail goes through a managed relay with a reputable sending address, which is what keeps your mail out of spam folders. Each tier includes a monthly message allowance and a daily send limit.
Past the included allowance, sending is $0.50 per 1,000 messages and mail storage is $0.30 per GB. Mail you receive is never metered.
Suspending a server stops it sending without powering it down, so nothing already delivered is lost and mail keeps arriving.
Every app gets a platform hostname, and you can attach a hostname under a domain you added to the account registry. With external DNS, add the record the app shows you. With managed DNS, Dilnaka Cloud publishes it automatically. Once the hostname resolves, the managed proxy serves the app and issues its TLS certificate.
Your container never listens on the public internet directly — it binds to the host's loopback interface, and traffic reaches it only through the managed proxy.
Read build logs, runtime output, and HTTP request logs per service, watch CPU and memory pressure, and track usage against your plan before it turns into an overage.
The Dilnaka CLI connects a terminal to your workspace. Version 0.0.8 is aligned with the current v1 Cloud API and needs Node.js 18.17 or newer.
$ npm install -g dilnaka-cli $ dilnaka login # approve the code in your browser $ dilnaka list # your projects and services $ dilnaka link commerce-api # tie this folder to a project (and app) $ dilnaka link --create # or create a new project, named after the folder $ dilnaka up # deploy its local source $ dilnaka up --new # deploy as a new app in the project $ dilnaka up --json # queue a deploy with script-safe JSON output $ dilnaka tunnel 3000 # temporary public URL for a local HTTP server $ dilnaka status # server, session, linked project
dilnaka login prints a short
code and opens your browser. You approve that code while already signed in, and the CLI
receives a personal access token — no password typed, no token pasted.
Use dilnaka login --force
to replace a still-valid local login. The
dilnaka status command now
distinguishes a rejected token from connectivity, server, and API compatibility errors.
Tokens are listed under
Account → CLI Tokens.
Revoking one stops that machine on its next command. For CI, create a token there and
expose it as DILNAKA_CLOUD_TOKEN.
Local and self-hosted control planes can be selected with
DILNAKA_CLOUD_API_URL.
Link a directory once, then run dilnaka up
from it. The CLI packages source using Git's ignore rules, leaves local
.env files out, and queues
a deployment for the linked app. A project can hold many applications:
dilnaka link --service <name-or-id>
pins the directory to one of them, and
dilnaka up --new deploys the
directory as a brand-new application inside the linked project. Starting from zero
never needs the dashboard:
dilnaka link --create makes
the project right from the terminal. The Cloud auth middleware now routes that command
through bearer-token authentication correctly rather than treating it as a browser page.
For automation, dilnaka up --json
keeps stdout strictly parseable JSON; progress and failures never contaminate the payload.
These commands are not available yet:
dilnaka connect — open a local port tunnelled to one of your databasesdilnaka variables / run — read service variables, run a command against themdilnaka logs / redeploy / rollback and service lifecycle controls
Run dilnaka tunnel <port>
to expose a loopback HTTP service through a random, short-lived public URL. The free
development tunnel uses an authenticated outbound connection, stores no relayed bodies,
and ends when the CLI disconnects. Persistent URLs and database/TCP access are separate
future features.
Start free on a shared instance, then move to a dedicated Custom instance whenever your workload is ready for it.