VS Code is where many people already write their READMEs, changelogs and docs. It edits and previews Markdown out of the box, and its integrated terminal is one keystroke away. That makes it a natural place to write a website — and to publish it.
This guide takes Markdown written in VS Code and publishes it with the Sentilis CLI, without leaving the editor.
1. Set up the content folder
Open a folder in VS Code (File → Open Folder) — a new one, or a folder inside an existing repository:
my-content/
├── bio/
│ └── en.md ← your profile page
└── press/
├── release-notes-2026-09.md
└── getting-started/
├── index.md ← main page
├── install.md ← section
└── attachments/
└── cover.png
press/ holds posts and documentation. A folder with an index.md is one entry, and every other .md next to it becomes a section.
2. Write and preview
Each file starts with a short settings block:
---
name: Getting started
category: Documentation
status: draft
---
# Getting started
Start with the [install guide](./install.md).
Open the built-in preview with Markdown: Open Preview to the Side to see the rendered page next to the source. Links between pages of the same entry use the file name, like ./install.md; images live in the entry’s attachments/ folder.
3. Install the CLI and log in
Open the integrated terminal (Terminal → New Terminal) and run:
npm i -g @sentilis/cli
sentilis auth login <your-token>
sentilis auth whoami
4. Validate, then publish
Check every entry without uploading anything:
sentilis sync ./my-content --dry-run
When everything passes, change status: draft to published in the files you want live, and publish:
sentilis sync ./my-content
Run the same command after every change. Pages keep their URL as long as their slug stays the same.
5. Make it a task (optional)
To publish without typing the command, add a VS Code task in .vscode/tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "Sentilis: sync",
"type": "shell",
"command": "sentilis sync ./my-content --strict"
}
]
}
Run it with Tasks: Run Task. --strict aborts the whole run if any entry has a problem, so nothing is half-published.
6. Publish from CI
If the folder lives in a Git repository, let CI publish on every merge instead. See publishing with GitHub Actions for a complete workflow, and docs as code for the review process around it.