The Obsidian Homepage plugin opens the file you choose, not the last one

A startup file instead of the last note you happened to open

Obsidian reopens whatever you had in front of you. That is convenient for a while and wrong for a vault that has grown into a workspace, because the file you land on is decided by whatever you happened to click last time. The Homepage plugin replaces that decision with a fixed one.

The plugin is published in the Obsidian community plugin list and is described as letting you set a specified note, canvas, base or workspace that opens on startup, launches from the sidebar, or is used as a command. By default it opens a note called `Home`, so installing it changes behaviour immediately, before you touch any setting. Everything else is configured in the `Homepage` pane of Obsidian's settings.

The target is not limited to a fixed file. You can pick any note, canvas, workspace or base as the homepage, and the plugin also offers to choose a random file, show the graph view, or display a Daily or Periodic Note. The Daily and Periodic options are not hardcoded behaviour either; the package depends on `obsidian-daily-notes-interface` and `obsidian-journals-api`, the community plugins that own those note types, which is how the plugin asks those plugins for a file rather than inventing its own calendar.

The other entry points are the same target reached differently. The `Open homepage` command and a dedicated ribbon button both jump back to the chosen file after startup, so the plugin doubles as a bookmark rather than only as a startup setting.

Old tabs can be kept, replaced or removed

The setting that deserves attention before you install is the one about what happens to the tabs you left open. The plugin offers three behaviours: keep them, replace the last note, or remove them all. That choice is not cosmetic, because Obsidian restores your previous session on launch and the plugin is deciding what survives that restore.

Keeping the tabs means you get your previous session plus the homepage, which is what most people want when they are mid-task. Replacing the last note is the middle ground, where one tab is swapped for the homepage. Removing them all gives a clean start with only the homepage open, which suits a vault used as a daily landing page rather than a working session.

The view behaviour is configurable in the same place. You can choose to open the homepage in Reading view, Source view, Live Preview, or the default view, and there is an option to revert the view when another note is opened afterwards. That second option matters for a particular habit: if you always want the homepage in Live Preview but your other notes in Reading view, the revert setting is what stops the homepage from dictating the view for the rest of the session.

None of this is documented as a command line or a config file. It is a settings pane, and the plugin is a window into Obsidian's own settings system rather than a tool with a scriptable interface.

Running an Obsidian command when the homepage opens

The option with the most leverage is the ability to run any Obsidian command upon opening the homepage. Because Obsidian commands are the plugin ecosystem's shared interface, this one setting turns the homepage into a trigger for anything the rest of your plugin set can do.

The project documentation frames this as allowing integration with thousands of possible actions from plugins. That is the point of using a command rather than a bespoke hook: the plugin does not need to know what your other plugins do, it just triggers a named command at a moment you control.

The same idea extends to the homepage content itself. The documentation notes that the plugin works effectively with plugins such as Dataview or Obsidian Bases to create advanced landing pages. A landing page can then be a note with query blocks that pull in your open tasks, your recent notes or a base view, and because that note is what opens at startup, the assembled page appears every time you launch Obsidian.

This is where the design earns its place. Without the command hook, a homepage is a static file you have to edit by hand. With it, the homepage is a script that runs on every launch.

Installing from the community list, and what BRAT gives you

Installation is the community plugin route. The recommended way is to download the plugin from the community repository, which is reachable from the `Community plugins` pane of Obsidian's settings. There is no build step for the end user and no manual copying of files into a vault.

Pre-release versions are a separate option. They can be installed manually or through tools such as BRAT, and the documentation attaches a warning to that route: specific revisions do not always undergo the full suite of testing that official releases receive. That is worth taking seriously, because the plugin runs a command on open and can restructure your session on launch, so a broken revision has more ways to annoy you than a broken static page would.

The stable route is the one to start with. The releases show a steady line of patches: 4.4.3 and 4.4.4 both shipped on 2026-06-03, and 4.5.0 followed on 2026-09-02. The repository is not archived and the last push was on 2026-09-12, so development continues a little ahead of the published version, which is the usual situation for an Obsidian plugin whose releases are cut from the same branch.

The plugin is MIT licensed, with the licence text in `LICENSE.md`, and the project page lives in the Obsidian community plugin directory.

A small TypeScript package built with esbuild

The repository is a conventional Obsidian plugin project: `src/` holds the TypeScript sources, `build.mjs` is the build script, `manifest.json` and `versions.json` carry the plugin metadata Obsidian reads, `styles.css` carries the styles, `tests/` holds the tests, and `eslint.config.mjs` and `tsconfig.json` cover linting and type checking.

The `package.json` describes a deliberately short toolchain. There are three scripts and they all call the same build file:

		"dev": "node build.mjs",
		"build": "node build.mjs production",
		"test": "node build.mjs test"

The production flag distinguishes a development build from a release build, and the test mode drives the test suite through the same entry point. Bundling is handled by esbuild with the type checking plugin `@jgoz/esbuild-plugin-typecheck`, and the linter uses `eslint-plugin-obsidianmd`, which is the set of rules written specifically for Obsidian plugin code rather than generic JavaScript rules.

Runtime dependencies are minimal: `obsidian` itself at version 1.13.0 or newer, plus the daily notes interface and the journals API, both used to resolve the Daily and Periodic Note options. The `opener` package in the development dependencies is what lets the build open the built plugin in Obsidian for testing.

Where the plugin stops being worth installing

The honest limit is scale. If your vault holds a handful of notes and you always want the one you were last reading, the plugin changes the behaviour of your editor without improving anything, and it adds a startup action that runs a command on every launch. The value scales with vault size and with how many plugins you have installed.

The second limit is the same one that applies to any landing page approach: the homepage is a file, and a file only shows what someone wrote into it. Without the command hook and without a plugin that queries your vault, it is a static note you now have to remember to update, and the risk is that it becomes stale and quietly stops being the page you look at.

The third limit is trust in the pre-release channel, which the project itself flags. If you install a specific revision through BRAT rather than the released version, the testing that official releases receive may not have been applied to it.

One thing the documentation does not address is any way to script the plugin, since the configuration lives in Obsidian's settings pane rather than in a file you could keep under version control. For a vault that is managed as code, that is a real limitation, and it means the plugin's behaviour travels with the vault rather than with a repository of settings.

Editorial conclusion

obsidian-homepage fits an Obsidian user whose vault has grown enough that reopening the last note is the wrong default, and it fits anyone who wants a landing page assembled by other plugins such as Dataview. It does not fit a vault with a single note, and it is a poor choice for anyone who wants the pre-release build, because the project states that specific revisions do not always get the full test suite that official releases receive. Before installing, check what happens to the tabs you left open in the Homepage settings pane, since the plugin can keep them, replace the last note or remove them all, and note that the current release is 4.5.0 from 2026-09-02 while the last push was on 2026-09-12.

Frequently asked questions

Official sources

1. License: MIT
2. mirnovov/obsidian-homepage on GitHub
3. Project website
4. README
5. Releases