Atlas VTT keeps the whole tabletop inside an Obsidian vault

A plugin inside Obsidian, on the desktop only

Atlas VTT is a virtual tabletop for tabletop RPGs that runs inside Obsidian, and the project describes it as game system agnostic. It is not a standalone application with its own window manager, its own file format for everything, or its own plugin ecosystem. It is an Obsidian plugin, which means the vault you already use is also the place where the game lives, and the familiar Obsidian link syntax carries over into the map itself.

The constraint that shapes everything is the desktop requirement. The project states that AtlasVTT is desktop only for now, and installation requires Obsidian 1.8.7 or newer on desktop. That rules out running a session from a phone, and it rules out mobile Obsidian as the client for the player view, so a second screen has to be a second computer display rather than a tablet.

The stated philosophy is local ownership. Every file the plugin creates, every token, every map and every world stays on your machine, in formats you control, with no account and no server in between. Atlas follows the same model as Obsidian itself, which is a coherent choice for people who already distrust cloud-only creative tools.

Two installation routes, one of them three files in a folder

The normal route is Obsidian's own community plugin browser. The project's steps are to open Settings, then Community plugins, turn off Restricted mode if it is enabled, select Browse, search for Atlas VTT, and then select Install and Enable. Updates arrive through the same panel.

The manual route exists for people who prefer to place the files themselves. Download main.js, manifest.json and styles.css from a GitHub release, put them in the .obsidian/plugins/atlas-vtt/ folder inside your vault, and enable Atlas VTT under Settings, Community plugins. One small oddity is worth noticing: the release link in that section points at a repository path under the ByteMirror account rather than the atlas-vtt organisation, so a careful installer will check where the artifacts actually come from.

For people who want unreleased builds, the project offers beta builds through BRAT, documented in docs/beta-testing.md. That matters because the beta channel is where the newest work lands. The release history shows 0.8.0 and 0.8.1-beta.0 both on 2026-10-14, preceded by 0.7.2-beta.0 on 2026-10-10, so tagged releases and beta tags ship close together.

Scenes are .atlasmap files, and the rest of the library is JSON

The storage model is the part of Atlas that deserves the most attention, because it is what separates this plugin from a web tabletop with a login. Scenes are saved as .atlasmap files, and everything else in the library, meaning tokens, encounters, collection settings and game system presets, is stored as JSON files in an atlas-vtt folder. Both live in the vault.

The practical consequence is that your campaign travels with the vault. If you sync the vault with Obsidian Sync, the project's documentation asks you to turn on the setting called Sync all other types so that the non-Markdown files are included. Nothing needs a separate export step and nothing needs a server round trip to be backed up.

For the plugin itself, the package metadata records the plugin as version 0.8.0 under the name atlas-vtt, and the licence field is the only-permissive-variant-free AGPL-3.0-only identifier.

  "version": "0.8.0",
  "license": "AGPL-3.0-only",

The build entry point is the same convention. The package scripts section drives the development loop with Vite, and the repository also defines separate test, lint and changelog entries.

    "build": "cross-env COPY_ON_CHANGE=false vite build",
    "test": "vitest --project unit",
    "lint": "eslint . --max-warnings 0 --suppressions-location eslint.suppressions.json",

The second window is the player view, and fog is the lever

At the table, the features cluster around what a game master actually does during a session. Fog of war and the player view are the headline pair: you reveal the map as players explore, and you can show a separate player window on a second screen while keeping game master information hidden. The first scene walkthrough in the project ends with exactly that step, opening the player view and moving it to a second screen for a local game.

Maps and grids are built from your own map images. Square and hex grids can be aligned manually or with automatic detection, which is the step right after importing an image and creating a scene from it. Tokens and encounters cover the rest: importing characters, moving and resizing tokens, and saving groups as reusable encounters. Creature notes can be linked through the optional Fantasy Statblocks plugin, and simple die syntax such as 2d8+2 becomes a clickable dice roll rather than a number you have to remember.

The rest of the toolkit is small conveniences that matter in play rather than in setup: sketching, adding text, measuring distances, pinning Markdown notes or other Atlas maps to locations, a roll log, an initiative tracker, counters and timers, audio from your vault, map hotkeys, and undo or redo for map edits.

Atlas Online is the hosted path, and it sits in closed beta

If you want to run a session over the internet, Atlas does not pretend the local model is enough. There is an online play service, Atlas Online, where a host runs a table that players join from their web browsers. It is described as a closed beta, it is off until you turn it on from the Experimental features page in the command palette, and hosting needs an Atlas account with closed beta access.

That is a genuine difference in approach rather than a feature checkbox. The local plugin keeps the world in your vault with no account, no telemetry and no ads. The hosted path reverses that: you sign in at the api.atlas-vtt.dev endpoint, a running table connects to play.atlas-vtt.dev, and that service passes the scene your players may see on to their browsers while keeping none of it. Players on the browser side need no account.

Two other network behaviours are documented plainly. If you use an external image URL for a token or map background, or copy an externally hosted image from a note, Atlas downloads that image from the supplied address; vault images need no network access. And when you explicitly submit an issue report, Atlas sends it to a report endpoint that creates a public GitHub issue, so bug reports are not private. The XLSX reader used by the random tables feature parses locally using the http://schemas.openxmlformats.org namespace identifiers and makes no requests to that address.

The hosted alternative comes with an account, and that is the trade

The obvious alternative to Atlas is the standard model for a virtual tabletop: a hosted service where the world, the account and the session all live on someone else's server, and every player connects to it. The difference in approach is exactly where the state lives. Atlas stores the campaign in the vault as .atlasmap files and JSON, so the source of truth is a folder you already control and can diff, sync or commit. A hosted tabletop makes the server the source of truth and the account the entry point.

The cost of Atlas's approach is that it inherits Obsidian's constraints. Desktop only, no mobile client, and the plugin is bound to Obsidian's release cycle and community plugin review. Its own online service, Atlas Online, is the hosted model implemented inside the same project, which is a useful way to see the trade-off the author made: keep the account and the server for the cases that need them, and keep the local vault for the cases that do not.

There is also a companion piece worth knowing about. Atlas Sidebar is a separate optional plugin that turns Obsidian's tabs into a vertical list with pinned tabs, folders, essentials and spaces, and keeps a pin at the top that returns to your scene in one click. It is a convenience layer rather than a requirement, and the core plugin stands without it.

AGPL-3.0-only, no telemetry, and a fast moving beta line

Licence and maintenance both point the same way. The package metadata records AGPL-3.0-only, and the repository root holds a LICENSE file alongside PRIVACY.md and THIRD_PARTY_NOTICES.md. AGPL-3.0 carries copyleft obligations that reach beyond ordinary source distribution, including network use, so if you intend to modify Atlas and offer it to others over a network, the licence terms need reading before you build on it. This is not legal advice, only the reason to open the file rather than assume it behaves like MIT.

On the privacy side the project's own account is short: it works offline with files in the vault, has no telemetry and no ads, and needs no account to use.

Activity is visible in the history. The repository is not archived and the last push was on 2026-10-22. Releases 0.8.0 and 0.8.1-beta.0 both went out on 2026-10-14, and 0.7.2-beta.0 on 2026-10-10, which is a pattern of small increments with beta tags landing alongside stable ones. The repository also carries a CHANGELOG.md, a changelog/ directory, a CONTRIBUTING.md, a CLA.md and a CLAUDE.md, plus ESLint and Tailwind configuration for the TypeScript sources under src/ and services/.

Editorial conclusion

Atlas VTT fits players and game masters who already keep their campaign in Obsidian, who want their maps, tokens and encounters as plain files they can grep, sync and back up, and who are willing to stay on the desktop. It is a poor fit if you need mobile play, if you want a hosted world without running the desktop app, or if AGPL-3.0-only licensing is a problem for your distribution. Check first that your Obsidian version is 1.8.7 or newer, that your vault sits somewhere the plugin can write .atlasmap files, and that you accept that online play is still gated behind closed beta access.

Frequently asked questions

Official sources

1. atlas-vtt/atlas-vtt on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases