Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/constanza101/borrissol/llms.txt

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

Borrissol deploys to Netlify via git push auto-deploy. Every merge to main triggers a production build; the result is published at borrissol.com. The site is a hybrid: all public-facing pages are statically prerendered at build time (zero Netlify Function invocations for ordinary visitors), while the Keystatic admin routes at /keystatic use SSR via a Netlify Function. This architecture keeps operating costs low while still supporting a dynamic CMS.

​
Build configuration

The entire Netlify build is controlled by netlify.toml at the repository root.
netlify.toml
[build]
  command = "npm run build"
  publish = "dist"

[build.environment]
  NODE_VERSION = "22.12.0"
SettingValueReason
commandnpm run buildRuns astro build, which prebuilds all static pages and bundles the SSR functions.
publishdistThe directory Astro writes its output to; Netlify deploys its contents.
NODE_VERSION22.12.0Pinned to match the engines field in package.json (>=22.12.0). Astro 6 requires Node 22+. Netlify defaults to an older LTS without this pin.

​
@astrojs/netlify adapter

The netlify() adapter (package @astrojs/netlify ^7.0.12) is declared in astro.config.mjs. It handles two responsibilities:
  1. Static output — All pages that do not require server-side rendering are emitted as pre-built HTML/CSS/JS into dist/. These are served directly from Netlify’s global CDN with no function invocation.
  2. SSR functions — The Keystatic admin routes (/keystatic/*) require a live server to authenticate requests and call the GitHub API. The adapter wraps these in a single Netlify Function automatically.
Public visitors never invoke an SSR function. The homepage, workshop pages, gallery, blog listing, and individual blog posts are all statically prerendered. Only Belén (the workshop owner) accessing /keystatic in production triggers function compute.

​
Bot-trap redirects

netlify.toml contains a block of [[redirects]] rules that return HTTP 404 at the Netlify edge layer for paths that only automated scanners and bots probe. Because these rules fire before any Astro code runs, a matched request never reaches the SSR function — saving both compute time and credits.
netlify.toml
# WordPress install/admin/login probes
[[redirects]]
  from = "/wp-admin/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/wp-login.php"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/wp-content/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/wp-includes/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/wp-config.php"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/xmlrpc.php"
  to = "/_blocked"
  status = 404
  force = true

# Stray PHP install/info probes
[[redirects]]
  from = "/install.php"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/phpinfo.php"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/admin.php"
  to = "/_blocked"
  status = 404
  force = true

# Common admin-tool path probes
[[redirects]]
  from = "/phpmyadmin/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/administrator/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/typo3/*"
  to = "/_blocked"
  status = 404
  force = true

# Source-control / secrets / config exposures
[[redirects]]
  from = "/.env"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/.git/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/config.php"
  to = "/_blocked"
  status = 404
  force = true

# Common backup/dump probes
[[redirects]]
  from = "/backup/*"
  to = "/_blocked"
  status = 404
  force = true

[[redirects]]
  from = "/backups/*"
  to = "/_blocked"
  status = 404
  force = true

​
Why these rules matter

Without them, every WordPress scanner probe that hits the site would invoke the Astro SSR function (1–3 seconds of compute per request) before returning a 404. On a shared hosting plan with a credit budget, continuous bot traffic can exhaust the monthly allowance within hours of a traffic spike. The edge-layer 404 approach costs essentially nothing.
Do not remove these bot-trap rules without first migrating to a platform with native bot protection (such as Cloudflare Pages, which includes Bot Fight Mode). Simply deleting the rules and relying on Astro’s 404 page would route all probe traffic through the SSR function.

​
Netlify credit model

Netlify’s paid plans are denominated in “credits” that cover both build compute and bandwidth. The table below shows the three relevant tiers.
PlanCredits/month~Deploys/month~Bandwidth
Free300~20~15 GB
Personal ($9/mo) ← current1,000~65~50 GB
Pro ($20/mo)3,000~200~150 GB
Credit consumption rules of thumb:
  • 1 production deploy ≈ 15 credits (build time + CDN invalidation)
  • 1 GB of bandwidth served ≈ 20 credits
  • Netlify Function invocations (SSR) consume credits from the same pool, charged by compute time
At the Personal plan’s 1,000 credits/month, you have roughly 65 production deploys before additional credits need to be purchased — or roughly 50 GB of traffic headroom if all credits go to bandwidth.

​
Cost control rules

Following these practices keeps the site comfortably within the Personal plan budget. Batch changes. Never push one commit per small fix. Accumulate related changes and push them together. One push = one deploy = ~15 credits. Use [skip ci] in the commit message for documentation, comment, or README-only changes that do not affect the built site. Netlify skips the build entirely when it sees [skip ci]. Keystatic keystatic/* branches do not trigger deploy previews. Deploy previews are disabled for these branches to avoid burning 15 credits on every draft save by the content author. Public visitors load static pages. No SSR function is invoked by ordinary site traffic. Only the /keystatic admin routes consume function compute, and only when the site owner is actively using the CMS. Monitor the Netlify dashboard. Check Team → Usage regularly. If bandwidth spikes (e.g. a blog post goes viral), investigate the source before the monthly credit pool is exhausted.
If the site grows to the point where 65 deploys/month is regularly tight, upgrading to the Pro plan ($20/mo, ~200 deploys) is more cost-effective than buying credit top-ups.

​
Deployment workflow

1

Verify the build locally

Before pushing, run a full production build locally to catch any errors:
npm run build
Astro will output the built site to dist/. Optionally preview it with:
npm run preview
2

Push to main

git push origin main
Netlify detects the push, clones the repository, runs npm run build, and deploys the dist/ directory to the CDN. The process typically takes 60–120 seconds.
3

Check deploy status

Open the Netlify dashboard and navigate to the Deploys tab for the Borrissol site. Confirm the deploy status shows Published. If it shows Failed, click the deploy entry to read the build log.

​
Deploy previews

Deploy previews are currently disabled for all branches to conserve credits. If you need to preview a feature branch before merging:
1

Enable temporarily

In the Netlify dashboard go to Site configuration → Build & deploy → Deploy contexts. Set Deploy previews to Any pull request.
2

Open the PR

Push your branch and open a Pull Request on GitHub. Netlify will post a preview URL in the PR comments.
3

Re-disable after review

Once the preview has been reviewed and the PR merged, return to Deploy contexts and set Deploy previews back to None to stop future branches from triggering builds.
Deploy previews for keystatic/* branches should never be re-enabled. Keystatic creates one branch per entry save; enabling previews for those branches would cost ~15 credits per auto-save.

Build docs developers (and LLMs) love

Get started for freeTalk to us