logo
Introduction

Introduction to self-hosted SlugBase

What SlugBase is, how self-hosted differs from cloud, terminology, and how these guides are written.

What you get with self-hosted SlugBase

Self-hosted SlugBase is an open-source bookmark manager you run on your own infrastructure. You save and organize bookmarks (title, URL, optional folders and tags), search from anywhere with Search (Ctrl+K), and optionally turn bookmarks into short links served at /go/<slug> for sharing and browser shortcuts.

The first account you create during initial setup is an administrator. From Admin in the app you can manage Users, teams, OIDC Providers, Settings (including SMTP), and AI Suggestions when you want OpenAI-powered title, tag, and slug hints while creating bookmarks.

Cloud vs self-hosted: The hosted product at slugbase.app adds organizations, plans, and billing on top of the same core app. Feature behavior that is the same in both editions is documented in these self-hosted guides unless a Cloud guide says otherwise.

Main areas of the app

After setup and login, the app is organized around routes such as the dashboard (/), Bookmarks (/bookmarks), Folders (/folders), Tags (/tags), and Profile (/profile). Slug forwarding uses /go/<slug>; Remembered Slug Choices is at /go-preferences (from Profile, open Manage remembered slug choices), and the in-app browser search-engine guide is at /search-engine-guide. Workspace administration is under /admin (tabs include Users, Teams, OIDC Providers, Settings, and AI Suggestions).

Terminology

TermMeaning
BookmarkA saved URL with metadata; a slug is optional.
SlugA short keyword that resolves to a bookmark URL via /go/... and browser shortcuts.
Self-hostedThe core product you install and run yourself (open-source license in the SlugBase repository).
CloudThe hosted multi-tenant service; app URLs are under https://slugbase.app/app/....

Where to go next

How these guides are structured

Guides follow a few repeatable shapes so you can scan quickly and follow procedures safely.

TemplateWhen we use itTypical sections
A — Install / configureDeployment and env topicsWhat you need → Steps → Verify → Troubleshooting
B — Feature guideUsing a product areaWhat it is for → Before you start → Steps for the main flow → Related links
C — Concept + taskIdeas like slugs or sharingShort concept (tables where useful) → Steps to configure → Optional FAQ-style expandables
D — FAQ / helpMany short answersCategory headings or expandables; links into deeper guides

Writing standards in this documentation

  • Task-first headings — Sections focus on what you will accomplish.
  • Second person, active voice — Instructions address you directly.
  • Progressive disclosure — Short overview, then prerequisites, then Steps, then troubleshooting when it helps.
  • UI labels — Bold names match the English in-app strings so what you read here matches what you see in the product.

Documentation.AI components we use

SituationComponent
Ordered procedures (install, first run, click-paths)<Steps> with <Step title="..." icon="...">
Notes, tips, warnings, success, danger<Callout kind="info | tip | alert | success | danger">
Long optional detail or FAQ<ExpandableGroup> / <Expandable title="..." default-open="false">
Alternatives (for example HTTP vs HTTPS proxy notes)<Tabs> / <Tab title="..." icon="...">
Multiple equivalent snippets (for example docker run vs Compose)<CodeGroup tabs="..." show-lines="true">
Hub / “where next” sections<Columns cols="2"> with <Card title="..." href="/…" icon="...">

API reference pages (when wired to OpenAPI) use different components reserved for request/response documentation; these guide pages stick to the components above.

Was this page helpful?

Last updated 2 days ago

Built with Documentation.AI