Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/santiagonieto09/portafolio/llms.txt

Use this file to discover all available pages before exploring further.

The portfolio is configured entirely through environment variables — there is no config file beyond vite.config.ts and vercel.json. The .env.example file at the project root lists every supported variable with inline comments. In production, set these variables through your hosting provider’s dashboard or CLI rather than committing a .env file; in local development, copy .env.example to .env and fill in the values you need.

​
Variables

​
GITHUB_TOKEN
string
A GitHub Personal Access Token sent as Authorization: Bearer <token> on all GitHub REST API requests made by the server.
Without a token the GitHub API applies the unauthenticated rate limit of 60 requests per hour per IP address. A single full page load can easily exhaust this on a busy server or during development. Setting a token raises the limit to 5,000 requests per hour, which is more than sufficient for a portfolio with weekly cron-based syncing. Use a classic Personal Access Token with no additional scopes — every endpoint the portfolio calls (/users/:username, /repos/:owner/:repo, /repos/:owner/:repo/releases, /repos/:owner/:repo/languages, /users/:username/events/public) is public-only and requires no OAuth permissions. The token is read exclusively on the server side via process.env.GITHUB_TOKEN (with process.env.GITHUB_API_KEY accepted as a fallback). It is never included in the client bundle and never sent to the browser.
​
CRON_SECRET
string
A shared secret string that must be supplied in the x-cron-secret request header (or as an Authorization: Bearer token) when calling POST /api/public/sync.
The sync endpoint triggers a full re-fetch of GitHub data and updates the server-side snapshot cache. Without access control, any external caller could force expensive GitHub API calls on demand. CRON_SECRET prevents this by requiring the caller to prove they know the secret. Requirements:
  • Should be at least 16 characters for practical security. Use a randomly generated string — for example, the output of openssl rand -hex 32.
  • The same value must be set both in the portfolio’s runtime environment and in whatever system calls the endpoint (a GitHub Actions secret, a cron service, etc.).
  • If CRON_SECRET is not set, the sync endpoint returns 503 Service Unavailable for all requests rather than exposing an unprotected mutation endpoint.
  • The comparison between the incoming header value and the stored secret is timing-safe (implemented with a byte-by-byte XOR check), preventing timing-based secret enumeration attacks.
​
SITE_URL
string
The canonical base URL of the deployed portfolio. Must include the scheme and hostname with no trailing slash, e.g. https://santiagonieto.dev.
SITE_URL is used in two places:
  1. sitemap.xml — Each <loc> entry is built by prepending SITE_URL to the route path. Without it, the sitemap derives the origin from the incoming HTTP request’s Host header, which is correct on most hosts but can produce inconsistent or private-network URLs when the app sits behind a reverse proxy or load balancer that rewrites Host.
  2. Open Graph meta tags — The og:url property on every page is set to SITE_URL + pathname, ensuring social share cards resolve to the canonical public URL rather than an ephemeral preview deployment URL.

​
Setting variables locally

Copy .env.example to .env in the project root and fill in your values:
.env
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
CRON_SECRET=a-long-random-secret-string
SITE_URL=https://santiagonieto.dev
Vite automatically loads .env at dev-server startup and injects server-side variables into the Nitro runtime. You do not need a VITE_ prefix for server-only variables.
Never commit .env to source control. The file is already listed in .gitignore. The .env.example file — which contains only empty placeholders and comment descriptions — is safe to commit and serves as the canonical reference for required variables.

​
Setting variables on Vercel

1

Open your project in the Vercel dashboard

Navigate to vercel.com/dashboard and select the portfolio project.
2

Go to Settings → Environment Variables

Click the Settings tab, then Environment Variables in the left sidebar.
3

Add each variable with the appropriate scope

For each variable (GITHUB_TOKEN, CRON_SECRET, SITE_URL), enter the name and value, then select the environment scopes where it applies:
  • Production — the main deployed branch (always required)
  • Preview — pull-request and branch preview deployments (recommended for GITHUB_TOKEN; use a separate CRON_SECRET or leave it unset)
  • Development — populated when using vercel env pull locally (optional)
4

Redeploy for changes to take effect

Environment variable changes are not applied to already-running deployments. Trigger a new deployment (push a commit, or use Deployments → Redeploy) for the updated values to be injected into the build and runtime.

​
Setting variables on Cloudflare Workers

Sensitive variables should be stored as encrypted secrets using Wrangler so they never appear in plain text in wrangler.toml or source control: 
wrangler secret put GITHUB_TOKEN
wrangler secret put CRON_SECRET
Wrangler prompts you to enter each value interactively and uploads it encrypted to the Cloudflare API. Secrets are injected into the Worker’s environment at runtime. SITE_URL is not sensitive, so it can be declared as a plain variable in wrangler.toml:
wrangler.toml
[vars]
SITE_URL = "https://santiagonieto.dev"
Plain [vars] are visible in the Cloudflare dashboard and in version control if you commit wrangler.toml — use this only for non-sensitive configuration.

Build docs developers (and LLMs) love

Get started for freeTalk to us