vscode-portfolio makes the route table the site model, so adding a page is one config entry

The whole site is a config file, not a set of pages

The portfolio is a Visual Studio Code themed developer portfolio site built with Next.js and deployed on Vercel, and its architecture is best understood by looking at what a user is expected to edit.

Personal details live in `portfolio.config.ts` at the project root. That file holds the `profile` with name, role, location, bio, site URL and SEO metadata, the `socials` shown on the Contact page and in the terminal's `contact` command, the `experience` and `writing` sections of the About page, the `extensions` list, the `projects` cards, and the `routes`.

The `extensions` entry is the cleverest of them. Each item in that list is a skill, and it is shown as an installed extension in the Extensions view, reachable with the Ctrl+Shift+X shortcut, with its own detail page. The About page's skills section and the terminal's `skills` command are both generated from the same list. So one array of skills produces three surfaces, and a visitor can click through to a detail page for a skill rather than seeing a flat list.

The `projects` entry produces the cards on the Projects page, and `socials` feeds both the Contact page and a terminal command, so the contact information is written once.

The `routes` entry is the one to look at twice, and it is covered in its own section below.

The result is a site that a developer can personalise without touching a React component, which is the right shape for a template that most people will use exactly once.

Routes drive the explorer, tabs, activity bar, palette and terminal

The `routes` configuration is the mechanism that makes this more than a skin. Each route sets its icon and, optionally, where it sits in the activity bar, its `G <key>` keyboard shortcut, and the file name and icon it shows in the explorer and in the tabs bar.

The payoff is stated directly: to add a page, you create `app/<route>/page.tsx` and add an entry to `routes`, and the explorer, tabs, activity bar, command palette and terminal pick it up automatically.

That is a lot of surface area to be driven by one list. In a conventional site, a navigation bar, a sidebar and a command palette would each be a separate piece of configuration that drifts apart. Here they cannot drift, because they are all reading the same array, which is why a new page shows up in all five places with a single entry.

The `G <key>` shortcut follows the same convention as the real editor, where a key plus a letter jumps to a view, so the muscle memory transfers. The file name and icon in the explorer and tabs bar is a smaller detail that does a lot of work for the illusion: a real editor shows a filename in the tab, and a portfolio that shows only a route path reads as a website wearing a costume.

The tradeoff is that the route model is one dimensional. There is no notion of a nested hierarchy, no per page layout override and no arbitrary content blocks, so a page that needs something the config cannot express requires a custom component anyway.

The terminal is the centrepiece, and it is interactive

The features roadmap lists an interactive custom terminal as done, alongside the theme work, and the terminal is the part that makes the site feel like an application rather than a picture of one.

The terminal exposes commands that mirror the editor's command palette, including `contact` and `skills`, both of which are generated from the same config entries as their page equivalents. That is the pattern the whole project follows. A command does not duplicate the site's data, it reads it, so the terminal and the page can never disagree.

The theme list is where the roadmap shows its remaining work. GitHub Dark is the default and is done, and Dracula, Ayu Dark, Ayu Mirage, Nord and Night Owl are also done. One Dark Pro is the only unchecked theme still outstanding, and the top level item, themes and customizations, is not finished as a whole. The README invites suggestions for other features and themes through issues.

The set of shipped themes is a good signal about the audience. Those are the themes developers actually use, which tells you the author optimised for the reader being a developer rather than for a designer, and the same instinct shows in the extensions view being populated with skills and the explorer showing file names.

A live deployment is at vscode-portfolio.vercel.app, and the README also carries an Open in Visual Studio Code button that points at the repository through vscode.dev.

Environment variables decide what the site fetches at build time

The credential model is simple and worth reading before you fork the project, because two of the three variables are secrets and one of them is not.

You copy `.env.example` to `.env.local` inside the project directory and fill in the values.

DEV_TO_API_KEY = your-api-key
GITHUB_API_KEY = your-api-key
NEXT_PUBLIC_GITHUB_USERNAME = itsnitinr

`DEV_TO_API_KEY` is your dev.to API key, used to fetch your articles, which is what populates the `writing` section. `GITHUB_API_KEY` is an optional GitHub token, and when it is set the GitHub API requests are authenticated, which raises the rate limit above 60 requests per hour. `NEXT_PUBLIC_GITHUB_USERNAME` is the GitHub username shown on the GitHub page, and because of the `NEXT_PUBLIC_` prefix it is inlined into the client bundle, which is why the example file ships with a real username in it.

The rate limit detail is the one that bites in practice. An unauthenticated GitHub API call from a serverless function is limited to 60 requests per hour, and a portfolio that renders a GitHub contribution calendar will exhaust that in minutes if a visitor reloads the page several times. Setting the token is the documented fix.

The other thing worth understanding is that these fetches happen at build time on Vercel, not on every request, which is why the token lives in a server side environment variable while the username is public. A fork deployed on Vercel needs the first two set in the project settings, and the same code run locally needs them in `.env.local`.

Bun, Next 16, React 19 and a small dependency list

The stack is current and the dependency list is short, which is notable for a site that reimplements a lot of editor chrome.

bun install
bun run dev

Bun is the package manager and the task runner here, and the lock file is `bun.lock` rather than a npm or pnpm lock. The npm scripts are the standard Next.js four, with `next dev`, `next build`, `next start` and `eslint .`.

The runtime dependencies are `next` at 16.4.1 or newer, `react` and `react-dom` at 19.3.1 or newer, plus `react-github-calendar` for the contribution graph and `react-icons` for the icon set. That is it. The VS Code look is not built on an editor component library, it is hand built from React components, and the repository puts all of the VS Code related components in a `components` folder.

The rest of the tree is conventional Next.js. There is `app/` for the routes, `lib/` for the data layer, `styles/` for the styles, `types/` for the TypeScript types, `public/` for static assets, and `next.config.ts`, `tsconfig.json` and `eslint.config.mjs` at the root. Two files stand out. There is an `AGENTS.md` for AI coding assistants and a `rule.mdc` file, which is a rules file in the format used by editor rule tooling, so the conventions for the project are expressed in a form an assistant can read directly.

There is a `CODE_OF_CONDUCT.md` and an MIT LICENSE at the root, the package is marked private with version 2.0.0, and the repository is not archived with the last push on 2026-10-14. There are no GitHub releases, so the version number in package.json is the only version signal.

Editorial conclusion

Adopt vscode-portfolio if you want a developer portfolio that looks like the editor you already use and you are comfortable editing a single TypeScript config file rather than a set of components. Do not adopt it if you need a CMS, a blog with authoring workflow, or per page control that the config model does not express, since everything flows through portfolio.config.ts. Verify first that the dev.to and GitHub credentials you supply are the ones you want embedded in a deployed page, that the route entries you write point at pages that exist under app/, and that the theme list covers the look you want before you build a personal brand on top of it.

Frequently asked questions

Official sources

1. Issues
2. itsnitinr/vscode-portfolio on GitHub
3. License: MIT
4. Project website
5. README