Built a terminal-inspired portfolio plus the publishing pipeline behind it: an Obsidian vault as the CMS, a GitHub Actions workflow that composes two repositories into one static artifact, and scheduled publishing without any server runtime.
Visitor selected.
Backend and cybersecurity work is difficult to present because the most valuable parts are often invisible: boundaries, ownership, failure handling, and proof.
The portfolio combines a strong terminal identity with project-specific case studies that let a visitor inspect the system instead of translating dense prose alone.
Writing had the same problem in reverse: a blog only survives if publishing costs nothing. The answer was to make the private Obsidian vault the CMS and let a pipeline turn a committed note into a deployed page, including notes dated for the future.
This site. A statically exported Next.js 16 application that doubles as the delivery surface for everything else in this portfolio: project case studies driven by typed data, long-form security write-ups, a markdown blog, and an interactive terminal with its own virtual filesystem.
OBSIDIAN IS THE CMS - Posts are written as plain markdown notes in a private Obsidian vault that is itself a git repository (PontoPe/ObsidianGit). There is no admin panel, no database, and no headless CMS to keep online. Publishing is "commit the note". A push in the vault fires a repository_dispatch event at the website repository, and the deploy pipeline checks the vault out into portfolio/_content with a scoped token, copies any referenced images into public/blog-images, and builds the blog routes from frontmatter using gray-matter.
SCHEDULED WITHOUT A SERVER - Frontmatter carries an ISO date. Future-dated notes are filtered out of both the blog index and generateStaticParams, and dynamicParams is disabled, so an unpublished post is not merely hidden - the route does not exist. Because a static export cannot decide at request time that "today" has changed, the deploy workflow also runs on a nightly cron at 00:17 America/Sao_Paulo: a post scheduled for a given date goes live on that date even if nobody commits anything.
CI/CD - One GitHub Actions workflow composes two repositories into one artifact: checkout public site, checkout private vault, npm ci on Node 24, collect images, next build (output: "export"), then FTP the out/ directory to the host. Triggers are push to main, the vault's repository_dispatch, the nightly cron, and manual dispatch. Every third-party action is pinned to a full commit SHA, the job runs with permissions: contents: read, and persist-credentials is disabled so the checkout token is never left behind in the runner's git config.
THE TERMINAL - The homepage carries "PontoPe OS", a client-side shell over a virtual filesystem defined in lib/virtualFS.ts: ls (with -a), cd, cat, tab completion for both commands and paths, plus shortcuts that route to the blog and a set of easter eggs ending in a Konami-code BSOD. It has no shell, no eval, and no network calls - the filesystem is a static object shipped with the page, so the whole thing is a self-contained interaction rather than an attack surface.
DELIVERY - Static export with trailingSlash for the FTP host, unoptimized images, hardened response headers, and no server runtime at all: the published artifact is a directory of HTML, CSS, JS, and images.
Publishing means committing a note in a private vault repository.
output: export plus trailingSlash, deployed as files over FTP.
Future-dated posts are absent from generateStaticParams, with dynamicParams disabled, and a nightly cron re-exports the site.
PontoPe OS is progressive enhancement over ordinary links and pages.
Case studies reuse behavior while varying visual and narrative emphasis.
Redaction is a content operation, not a CSS effect.
01# Publishing = committing a note. The vault dispatches; this workflow builds.02on:03 push: { branches: [main] }04 repository_dispatch: { types: [update_blog] } # fired by the Obsidian vault05 schedule:06 - cron: '17 0 * * *' # future-dated posts go live07 timezone: "America/Sao_Paulo"08 workflow_dispatch:09 10permissions:11 contents: read # least privilege for the job12 13jobs:14 web-deploy:15 runs-on: ubuntu-latest16 steps:17 - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.118 with: { persist-credentials: false } # no token left in .git/config19 20 - name: Get private content (Obsidian)21 uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.122 with:23 repository: PontoPe/ObsidianGit # private vault = the CMS24 token: ${{ secrets.GH_PAT }}25 path: portfolio/_content26 persist-credentials: false27 28 - run: npm ci && npm run build # next build -> static exportTwo repositories, one artifact: the private Obsidian vault is checked out into the site, then the static export is shipped. Actions pinned by SHA, read-only permissions, credentials never persisted.
The post waits, and the site keeps serving the previous deploy.
The build continues and produces a site with no blog posts rather than a broken deploy.
It is excluded from the index and from the generated routes, so the URL 404s until its date.
Typed build validation surfaces missing required content.
No control is presented as total risk elimination.
Publishing a post costs one commit in Obsidian and nothing else
Scheduled writing goes live on its own date without a server or a database
Two repositories, one of them private, build into a single static artifact with least-privilege credentials
Invisible engineering work becomes inspectable through case studies that share one system