Plans Sign In Register

Your Assistant in the Cloud

Wiki

Your Assistant in the Cloud

Running DMJBot on a server instead of your own laptop changes one thing that matters more than it sounds: the bot is available even when you are not at your desk. Scheduled work runs, long tasks finish, and you can reach the same assistant from a phone, a tablet, or any browser.

This guide is the full path: where to run the bot, how to reach it from the mobile apps, and how to connect your machines to it so the bot can still work on your local files and tools.

Why run it on a server

  • Always on. Assignments fire on schedule and on events, and background tasks keep running, whether or not your laptop is open.
  • Reachable from anywhere. Web browser, Android app, iOS app — all talking to the same bot, the same chats, the same history.
  • Separated from your work machine. The bot does not share a machine with your daily work; it only reaches what you explicitly connect.
  • Still local where it matters. Your laptops, desktops and home servers connect to it as devices, so the bot can work on real files on real machines.

A DMJBot instance is small — it is an orchestrator, not a model. It does not need a GPU, and a modest VPS is enough.

Step 1 — Choose where it runs

Option A: your own hosting

Run the container anywhere you control: a VPS, a home server, a NAS, a cloud VM.

docker run -d \
	--name dmjbot \
	--restart unless-stopped \
	-p 8080:80 \
	-v dmjbot-data:/data \
	dmjbot/dmjbot:latest

Notes for a server (rather than a laptop) install:

  • Use --restart unless-stopped so the bot comes back after a reboot.
  • Keep /data on a named volume or bind mount and back it up — it holds your sessions, settings and files.
  • More deployment options (MySQL/PostgreSQL backends, compose files, environment overrides) are on the Extended Installation page.

Self-hosting is free. Your data, your API keys, your machine.

Option B: we host it for you

If you would rather not run and maintain a server, we can run the instance for you: your own dedicated bot on your own URL, with updates and backups handled. The software is identical — the same web interface, the same mobile apps, the same device connections. You keep using your own LLM provider keys.

See the Plans and Pricing page for the available options.

Step 2 — Give it a URL and HTTPS

Once the bot is not on localhost, put it behind a proper address before you sign in from anywhere else:

  1. Point a domain or subdomain at the server, for example bot.example.com.
  2. Enable HTTPS. Both a reverse proxy and DMJBot's built-in TLS are supported — see the SSL/TLS Setup guide.
  3. Set a strong admin login and password during first-run setup (see Getting Started).

HTTPS is not optional for a public instance: the web interface and the mobile apps carry your chat content and access tokens over this connection. Managed instances come with a domain and certificate already configured.

Finish the first-run setup in a browser — model provider, credentials, admin login — exactly as described in Getting Started.

Step 3 — Connect the mobile apps

The DMJBot mobile apps are free and connect to your instance. There is no account on our side to create for them.

Android app | iOS app

To connect:

  1. Install the app on your phone or tablet.
  2. Open it — the first screen asks for Server URL, Login and Password.
  3. Enter your instance URL, for example https://bot.example.com, and the same login and password you use in the web interface.

You then get the same workspace you have on the desktop: your chats and history, assignments, running background tasks, projects and file attachments — kept in sync, because both clients talk to the same bot.

Install the app on as many devices as you like; they are all clients of the same instance.

What the apps do not do: settings management and tool/device connection are intentionally limited on mobile. Configuring models, tools, MCP servers and devices is done in the web interface — which also works in a mobile browser if you need it while away from a computer.

Step 4 — Connect your devices

A cloud-hosted bot is not cut off from your machines. Install the DMJBot Bridge on each machine you want the bot to work on:

# Linux and macOS
curl -fsSL https://dmjbot.com/bridge/install.sh | bash
# Windows (PowerShell)
iwr -useb https://dmjbot.com/bridge/install.ps1 | iex

Then, in the web interface, go to Settings → Devices, add a device, and use the connect URL it shows:

dmjbot-bridge connect <connect_url>
dmjbot-bridge service install

Running it as a service (service install) is what you want for a cloud setup — the device reconnects on its own after a reboot, so the bot can reach it without you doing anything.

Two properties make this work well with a remote bot:

  • The bridge connects outbound. The device opens the connection to your instance, so it needs no public IP, no port forwarding and no firewall changes. A laptop on home or hotel Wi-Fi connects the same way a server does.
  • Only what you install is exposed. The bridge exposes the MCP servers you installed and configured on that machine — nothing else. See Devices for the full security model.

More than one device

You can connect several devices to the same instance and use them in the same conversation — a desktop, a home server, an old laptop, a work machine. Each one shows up separately in Settings → Devices, with its own set of tools, and the bot can move work and files between them.

A common layout:

Where What runs there Typical role
Cloud instance DMJBot itself Always-on brain: chats, assignments, tasks, memory
Desktop / laptop Bridge + file, git, command, agent MCP servers Real work on real projects and files
Home server / NAS Bridge + storage MCP servers Long-term files, downloads, backups
Phone / tablet Mobile app Ask and monitor from anywhere

What to run where

  • In the cloud instance: the bot, its database, its schedule, and any HTTP-based MCP servers (bundled tools, external APIs). These must be up 24/7.
  • On a device: anything that needs access to local files, local repositories, local networks, or other AI agents such as Claude Code or Copilot. A device may be offline sometimes; tools on it are simply unavailable until it reconnects.

If an assignment must run unattended at 6 a.m., prefer tools that live in the cloud instance or on a device that is always on.

See also