holas.pl is a static site with one exception: the contact form. Every blog post, category page, and static page is a pre-rendered HTML file served by nginx. The contact form is the only endpoint that runs PHP.

That single exception raises a specific security question: how do you protect a form on a static page from bot submissions and CSRF attacks when there's no session?

The CSRF Problem with Static Pages#

Standard CSRF protection works by embedding a token in the form that is tied to the user's session. When the form is submitted, the server verifies the token matches the one in the session.

Static pages don't have sessions. The contact page is generated once during ddev build and served as a file. It can't generate a per-user token at render time. Symfony's built-in csrf_protection is therefore explicitly disabled on the contact form:

public function configureOptions(OptionsResolver $resolver): void
{
    $resolver->setDefaults([
        'csrf_protection' => false,  // deliberate — static page, no session
    ]);
}

Disabling CSRF protection is the right call here. The alternative — adding a dynamic PHP endpoint just to generate tokens for the form — would reintroduce the PHP-on-every-request problem for a page that otherwise needs none.

Cloudflare Turnstile as the Replacement#

Cloudflare Turnstile is a CAPTCHA alternative that runs client-side, confirms the user is human, and provides a one-time token that can be verified server-side. It replaces CSRF as the bot-prevention layer.

The form flow:

1. The contact page is served as static HTML with the Turnstile widget embedded (site key baked in at build time)
2. Turnstile runs its challenge invisibly; on success it calls window.onTurnstileSuccess(token), which writes the token into a hidden field
3. contact.js intercepts the form submit event and sends the data via fetch() instead of a standard form post
4. The PHP endpoint receives the submission, validates the form fields, then verifies the Turnstile token with Cloudflare's API
5. Only if both pass does the email get sent

Server-side verification is the critical step:

final class TurnstileValidator
{
    public function verify(string $token, string $remoteIp): bool
    {
        try {
            $response = $this->httpClient->request('POST', 'https://challenges.cloudflare.com/turnstile/v0/siteverify', [
                'body' => [
                    'secret'   => $this->secretKey,
                    'response' => $token,
                    'remoteip' => $remoteIp,
                ],
            ]);

            $data = $response->toArray();

            return true === ($data['success'] ?? false);
        } catch (\Throwable $e) {
            $this->logger->error('Turnstile verification failed: '.$e->getMessage());

            return false;
        }
    }
}

The validator fails closed — any exception returns false and blocks the submission. An empty or missing token also returns false immediately.

Minimal PHP Attack Surface#

The entire application's PHP surface in production is two URL patterns:

location ~ ^/(api|pl/api)/ {
    fastcgi_pass $php_upstream;
    fastcgi_read_timeout 30;
}

Everything else — every blog post, every category page, the sitemap, the RSS feed, the search page — is handled by nginx serving static files. PHP-FPM is never invoked for content delivery. The attack surface for the PHP layer is a single POST endpoint.

Content Security Policy#

The nginx config applies a strict CSP on every response:

add_header Content-Security-Policy
    "default-src 'self';
     script-src  'self' challenges.cloudflare.com;
     style-src   'self' 'unsafe-inline';
     img-src     'self' data:;
     frame-src   challenges.cloudflare.com;
     connect-src 'self' challenges.cloudflare.com;"
    always;

The only external domain permitted is challenges.cloudflare.com, which Turnstile requires for its script, iframe, and API call. No Google Analytics, no CDN scripts, no Facebook pixel. script-src has no 'unsafe-inline' and no 'unsafe-eval' — all JavaScript is loaded from hashed files via Symfony AssetMapper.

The 'unsafe-inline' in style-src is a deliberate compromise: Turnstile's widget injects inline styles that can't be avoided without a CSP nonce, and AssetMapper doesn't currently inject nonces. Everything else is locked down.

Additional Security Headers#

add_header X-Frame-Options        "SAMEORIGIN"                       always;
add_header X-Content-Type-Options "nosniff"                          always;
add_header Referrer-Policy        "strict-origin-when-cross-origin"  always;
add_header Permissions-Policy     "camera=(), microphone=(), geolocation=()" always;

Hidden files are denied:

location ~ /\. { deny all; }

HSTS is handled upstream at Cloudflare, so there's no Strict-Transport-Security header in the nginx config — it would be redundant.

The Result#

The contact form works without sessions, without CSRF tokens, and without JavaScript being required for anything other than the form submission itself. The page renders fully as static HTML. Bot submissions are blocked by Turnstile's server-side verification. The PHP endpoint is unreachable for anything other than POST requests to /api/contact.

Compared to WordPress with a contact form plugin, the attack surface went from "PHP running on every request, wp-admin exposed, XML-RPC enabled, 22 plugins any of which could have a vulnerability" to "one POST endpoint with Cloudflare verification."

The next post covers the developer experience — DDEV, the build pipeline, and deployment to production in two Docker containers.

The codebase is open-source under Apache 2.0 — see GitHub / notACMS. It has 368 PHPUnit tests, CI/CD via GitHub Actions, and a local override pattern that lets users customise templates, CSS, and translations without forking.

Architecture#

All content lives in Markdown files with YAML frontmatter:

content/
├── blog/
│   └── tutorials/
│       └── my-post/
│           ├── en.md   ← English version
│           ├── pl.md   ← Polish version
│           └── files/  ← images, served at /media/my-post/
└── pages/
    └── about/
        ├── en.md
        └── pl.md

ContentTreeBuilder scans the filesystem, parses each file with league/commonmark (GitHub Flavoured Markdown + YAML frontmatter), and builds a typed ContentTree — an in-memory index of all posts and pages for a given locale. Tags, categories, archive months, and URL maps are computed from that index.

The static build uses Symfony sub-requests: HttpKernelInterface::handle() with SUB_REQUEST renders every URL through the full kernel without touching the network. If a URL works in development, it will be in the static build. No separate template engine, no build configuration.

Key Features#

• Multi-language — co-located en.md + pl.md in the same directory, automatic translation mapping, hreflang tags, language switcher
• Search — Pagefind WASM-based static index, client-side, no Elasticsearch or Algolia
• Responsive images — automatic srcset generation via ImageMagick, configured variant widths
• Draft & scheduled posts — dev-only preview toggles, scheduled posts automatically published at build time
• Contact form — Cloudflare Turnstile CAPTCHA, tight CSP, single POST endpoint
• Styleguide — dev-only page documenting every component with real CSS classes
• Local override pattern — local/ directory merges on top of base at build time, customise without forking

Tech Stack#

• PHP 8.5, Symfony 7.x
• Twig templates, SCSS (dart-sass via symfonycasts/sass-bundle)
• Symfony AssetMapper (no webpack, no Vite, no Node.js build pipeline)
• nginx + PHP-FPM (two Docker containers in production)
• Pagefind for search
• PHPUnit 13, PHPStan level 6, Rector, PHP CS Fixer

Why Build It?#

Hugo, Jekyll, and Eleventy were obvious candidates. I chose to build a custom Symfony application because I already know Symfony well, and owning the full stack turned out to have real advantages: the same templates, controllers, and content pipeline serve both development and production. There is no "build-time template engine" separate from the "runtime template engine." It's just Symfony.

The full story of why WordPress had to go is in Why I left WordPress. The architecture deep dive is in Symfony as a Static Site Generator.

Open Source#

notACMS is available on GitHub under Apache 2.0. The preparation for release — testing, AI code review, security fixes, the local override pattern — is documented in the open-source series.

After deciding to leave WordPress, the question was what to replace it with. Hugo, Jekyll, and Eleventy were obvious candidates. I chose to build a custom Symfony application instead — not because the existing tools are inadequate, but because I already know Symfony well, and owning the full stack turned out to have real advantages.

The Core Idea#

The site works in two modes:

• Development — Symfony handles requests dynamically. Edit a Markdown file, refresh the browser, see the result. Standard Symfony dev workflow with the profiler toolbar.
• Production build — a single console command renders every URL to an HTML file on disk. nginx serves those files directly. PHP is never called for content delivery.

The same templates, controllers, and content pipeline serve both modes. There is no "build-time template engine" separate from the "runtime template engine." It's just Symfony.

Content Pipeline#

All content lives in Markdown files with YAML frontmatter:

content/
├── blog/
│   └── tutorials/
│       └── my-post/
│           ├── en.md   ← English version
│           ├── pl.md   ← Polish version
│           └── files/  ← images, served at /media/my-post/
└── pages/
    └── about/
        ├── en.md
        └── pl.md

ContentTreeBuilder scans the filesystem, parses each file with league/commonmark (GitHub Flavoured Markdown + YAML frontmatter), and builds a typed ContentTree — an in-memory index of all posts and pages for a given locale. Tags, categories, archive months, and URL maps are computed from that index.

ContentItem is a final readonly value object. No database, no ORM, no migrations. Adding a post means creating a directory with two Markdown files and running the build.

The Build Command — Symfony Sub-requests#

The static build uses a technique that's specific to Symfony and distinguishes this approach from Hugo or Jekyll: it calls HttpKernelInterface::handle() to make sub-requests — internal PHP calls that go through the full Symfony kernel without touching the network.

$request = Request::create($url);
$request->attributes->set('_static_build', true);
$response = $this->kernel->handle($request, HttpKernelInterface::SUB_REQUEST, false);

if ($response->getStatusCode() < 400) {
    file_put_contents($outputPath, $response->getContent());
}

For every URL — blog posts, category pages, tag pages, archive months, static pages, error pages, RSS feeds, the sitemap — the build command creates a request, runs it through Symfony, and writes the HTML to disk. The URL /blog/ becomes public/static/blog/index.html. The URL /sitemap.xml becomes public/static/sitemap.xml.

No separate template engine to learn. No build configuration. If a URL works in development, it will be in the static build.

nginx Serves Everything#

In production, nginx handles all content delivery:

location / {
    try_files /static$uri/index.html /static$uri/index.xml /static$uri $uri =404;
}

# PHP only for the contact form
location ~ ^/(api|pl/api)/ {
    fastcgi_pass $php_upstream;
}

For any incoming URL, nginx tries the pre-rendered HTML file first. PHP-FPM is only invoked for /api/contact — the single dynamic endpoint. Every blog post, category listing, tag page, and static page is a file served directly from disk. A Raspberry Pi 5 handles this trivially.

No Database#

The content tree is built from Markdown files at build time. In production it's cached indefinitely in Symfony's filesystem cache (invalidated and rebuilt on every deploy). In development it's rebuilt on every request so file changes are immediately visible.

There is no MySQL, no schema, no migrations, no connection pooling, no slow queries. Adding content means creating files and running ddev build. Removing content means deleting files. The entire site history is in git.

Multi-language Without a Database#

Both Polish and English content lives in the same directory:

content/blog/tutorials/my-post/
    en.md  → slug: "blog/my-post"      → /blog/my-post/
    pl.md  → slug: "wpisy/moj-wpis"    → /pl/wpisy/moj-wpis/
    files/ → images served at /media/my-post/

Co-location is the translation link. Two locale files in the same directory are automatically treated as translations of each other. TranslationMapBuilder constructs {directoryKey → {locale → url}} for hreflang tags and the language switcher. No translation_key field, no join table, no synchronisation to manage.

Search with Pagefind#

Search is a WASM-based static index built by Pagefind after the HTML files are generated:

npx pagefind --site public/static --output-path public/pagefind

Pagefind reads the pre-rendered HTML, indexes data-pagefind-body regions, and generates a binary index in public/pagefind/. The search page loads this index client-side via a dynamic import(). No Elasticsearch, no Algolia, no server-side search query. The index is a set of static files.

Redesign Simplicity#

Changing the site's appearance means editing Twig templates and SCSS. No React component library to update. No Node.js build pipeline. No WordPress child theme hierarchy. The entire frontend is:

• assets/styles/app.scss — one entrypoint importing partials
• templates/ — Twig templates
• symfonycasts/sass-bundle — compiles SCSS with dart-sass, no Node required

To change the colour scheme: edit _variables.scss. To change the layout: edit a Twig template. Run ddev build and it's done.

Trade-offs#

The main trade-off compared to Hugo or Jekyll is that this is custom code — I maintain it. The upside is that it's exactly what's needed, nothing more. There's no plugin ecosystem to navigate, no upgrade path to worry about, no feature flags for things I'll never use.

The only genuinely dynamic feature — the contact form — is covered in the next post.

This is the first post in a series documenting the migration to a custom Symfony-based static site generator. The next posts cover the architecture, the contact form, the developer workflow, and building the site with AI assistance.

The Update Treadmill#

WordPress ships security updates frequently. Plugins ship updates independently. Themes do too. On a quiet week my update queue had three items. On a bad week it had fifteen. Each one required:

1. Back up the database and files
2. Apply the update
3. Check that nothing broke

That last step is the killer. WordPress plugins interact with each other in ways that are impossible to predict. An update to a caching plugin would break the SEO plugin's output. An update to the SEO plugin would change how sitemaps were generated. Every update was a small gamble.

For a portfolio site that publishes a post every few months, this maintenance overhead is absurd.

Dozens of Plugins for Basic Features#

A fresh WordPress installation does almost nothing useful. To run a respectable portfolio blog you need plugins for:

• SEO — Yoast or Rank Math, with their own settings screens, meta boxes, and update cycles
• Caching — W3 Total Cache or WP Super Cache, with complex configuration and edge cases
• Security — Wordfence or similar, scanning for intrusions, blocking IPs, sending daily reports
• Contact form — Contact Form 7 or Gravity Forms
• Backups — UpdraftPlus or similar, usually pushing to an external service
• Performance — image optimization, lazy loading, minification
• SMTP — because WordPress sends email through PHP mail() by default, which goes to spam

Each plugin is code you don't control, maintained by someone else, potentially abandoned tomorrow, running on every page load.

When I started planning the migration I counted 22 active plugins.

Bot Attacks and Login Problems#

A WordPress login page is a known target. The URL is always /wp-admin/ or /wp-login.php. Every bot on the internet knows this. The result: constant brute-force login attempts, around the clock.

I had Wordfence rate-limiting login attempts, blocking suspicious IPs, and sending me daily attack reports. It worked — but it was another moving part consuming server resources on a site that didn't need user logins at all. The only person logging in was me, once a month.

XML-RPC was another attack vector. WordPress enables it by default for pingbacks and the mobile app. Bots probe it constantly. The fix was an nginx rule to block it — but you only find out about it after seeing the traffic in your logs.

PHP and MySQL on a Raspberry Pi#

holas.pl runs on self-hosted hardware — first a Banana Pi, now a Raspberry Pi 5. These are capable ARM boards, but they are not server-grade machines. Running PHP-FPM and MySQL simultaneously for a blog that changes once a month is wasteful.

A typical WordPress page load on that hardware: PHP parses the request, MySQL runs several queries to fetch post content, navigation data, sidebar widgets, and site options, PHP renders templates, every active plugin executes its hooks. All of this for content that was identical to the last request and will be identical to the next one.

With a static site, nginx serves a pre-rendered HTML file directly from disk. The ARM processor barely wakes up. Pages load faster than WordPress could parse the incoming request.

The Database as a Liability#

Nineteen years of WordPress produces a database with thousands of rows of post metadata, options, post revisions, and transients. It needs:

• Regular backups (and testing that restores actually work)
• Occasional cleanup — WordPress accumulates garbage: post revisions, expired transients, orphaned metadata rows
• Monitoring for corruption after unclean shutdowns
• A MySQL process running continuously, consuming memory

A portfolio blog is a collection of text and images. Storing it in a relational database adds operational complexity without adding value.

What I Kept#

The content. All 26 posts were exported and converted to Markdown files — titles, dates, categories, tags, images. The URLs were preserved exactly: 25 individual post redirects and 43 image path redirects are now baked into the nginx config. Search rankings survived the migration intact.

Everything else — the database, the plugins, the update queue, the /wp-admin/ login page — is gone.

The next post covers what replaced it: a custom Symfony application that generates static HTML files and serves them through nginx, with no PHP involved in delivering content to visitors.

Traefik is a reverse proxy designed for container environments. It watches the Docker socket, discovers running containers, and automatically provisions Let's Encrypt certificates — no certbot, no cron, no manual config per domain.

The setup is split into two parts: a single Traefik instance that runs permanently, and per-service labels that tell Traefik how to route and which domain to certify.

Part 1 — Traefik docker-compose.yml#

This runs once on the server. All other services route through it.

services:
    traefik:
        image: traefik:${TRAEFIK_VERSION}
        container_name: traefik
        command:
            - "--providers.docker=true"
            - "--providers.docker.exposedbydefault=false"
            - "--entrypoints.web.address=:80"
            - "--entrypoints.websecure.address=:443"
            # global HTTP → HTTPS redirect
            - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
            - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
            # Let's Encrypt
            - "--certificatesResolvers.le.acme.email=${ACME_EMAIL}"
            - "--certificatesResolvers.le.acme.storage=acme.json"
            - "--certificatesResolvers.le.acme.tlsChallenge=true"
        restart: always
        ports:
            - 80:80
            - 443:443
        networks:
            - web
        volumes:
            - /etc/localtime:/etc/localtime:ro
            - /var/run/docker.sock:/var/run/docker.sock
            - ./acme.json:/acme.json
        labels:
            - traefik.http.middlewares.gzip.compress=true

networks:
    web:
        external: true

A few things worth noting:

• exposedbydefault=false — Traefik ignores containers unless they explicitly opt in via labels. Nothing gets exposed accidentally.
• TLS challenge — Traefik handles certificate issuance on port 443 directly. No need to temporarily expose port 80 for verification.
• acme.json — certificates are persisted to disk and survive container restarts. Create this file and set strict permissions before the first run:

touch acme.json && chmod 600 acme.json

Traefik will refuse to start if the file has looser permissions.

• External web network — create it once:

docker network create web

Every service that needs HTTP/S routing joins this network.

Part 2 — Staging certificates for testing#

Before going live, test with Let's Encrypt's staging server to avoid hitting rate limits:

# add to traefik command:
- "--log.level=DEBUG"
- "--certificatesresolvers.le.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"

Staging certs aren't trusted by browsers but are functionally identical for testing. Remove these lines when everything works.

Part 3 — Adding a service#

This is where it pays off. Any container gets HTTPS by adding four labels:

services:
    myapp:
        image: myapp:latest
        networks:
            - web
        labels:
            - traefik.enable=true
            - traefik.http.routers.myapp.rule=Host(`myapp.example.com`)
            - traefik.http.routers.myapp.entrypoints=websecure
            - traefik.http.routers.myapp.tls.certresolver=le

networks:
    web:
        external: true

Traefik picks up the container, requests a certificate from Let's Encrypt, and starts routing — no nginx config, no certbot run, no cron. Renewals happen automatically in the background.

Bare-metal alternative#

If you're not using Docker, Certbot with the nginx plugin is the standard approach: apt install certbot python3-certbot-nginx, run certbot --nginx -d mysite.com, and a systemd timer handles renewals. Works well for a single server with a handful of sites. Once you're managing more services, the Traefik approach becomes worth the initial setup.

Hardware specification#

The new setup was put together with maximum responsiveness and stability in mind:

• Unit: Raspberry Pi 5 (8 GB RAM).
• Case: Argon NEO 5 M.2 NVMe — provides effective cooling and direct SSD support through a dedicated interface.
• Storage: Lexar 1 TB M.2 PCIe NVMe NM620. Moving from micro SD to NVMe significantly reduces latency and increases media durability.

Energy efficiency#

One of the key arguments for choosing a Raspberry Pi as a 24/7 server is its low power draw. In the current configuration:

• Idle: Power consumption at 3 W (confirmed by a power meter reading).
• Stress (load): Power consumption rises to 9–12 W.

The performance-to-energy ratio makes this unit an extremely cost-effective solution.

System and OS-level services#

Everything runs on Raspberry Pi OS. At the operating system level (outside Docker) I configured the key management and access services:

• Remote access: A VPN based on the Wireguard protocol (PiVPN) provides a secure tunnel into the home network.
• Management: I use VNC for graphical interface access.
• File sharing: A standard Samba service for fast data access on the local network.

Docker environment#

The key change compared to the previous server is full containerization of network services. Traefik handles routing and automatic SSL certificate issuance.

Within Docker I currently maintain:

1. holas.pl — my website.
2. Nextcloud — a private cloud for data synchronization.
3. Immich — a solution for photo library backup and management.
4. Traefik — a reverse proxy managing incoming traffic.

Growth potential#

Despite running several demanding services, the 8 GB Raspberry Pi 5 shows plenty of headroom in both computing power and RAM. Current utilization allows for adding more containers without any risk of degrading the already running systems. Moving to the NVMe standard means that database operations (especially in Immich and Nextcloud) are now instantaneous.

After a year of internal use it reached v1.0.0, with full Sylius 2.x support, a clean structure, and everything I use day-to-day. Version 1.0.1 followed the next day with cross-platform fixes.

Why Sylius setup is painful without tooling#

Sylius 2.x has a non-trivial local setup. It requires PHP 8.4, Composer, a database, a web server with the correct rewrite rules, Node.js and Yarn for compiling the admin assets (based on Webpack Encore), and the Symfony binary for console tasks. Getting all of those running consistently across developer machines — Windows, macOS, Linux — without a container setup is fragile. Versions drift, environment variables differ, paths conflict.

DDEV solves this by declaring the entire environment as configuration. The boilerplate bakes in the correct versions and wires them together so no one has to figure it out manually.

What it configures#

The .ddev/config.yaml sets:

• PHP 8.4 with apache-fpm (Sylius 2.x requires PHP 8.2+; 8.4 is current stable)
• MariaDB 11.8 — latest stable, with upload_dirs tuned to exclude media/, node_modules/, and backups/ from Mutagen sync on macOS
• Composer 2
• Ports 8123 (HTTP) and 8443 (HTTPS) to avoid conflicts with other local projects
• Xdebug disabled by default — enable with ddev xdebug on when needed

What's included#

ddev-sylius is a DDEV-based project template for Sylius 2.x. Clone it, run two commands, and you have a working local Sylius instance — no manual configuration of PHP versions, database, or web server.

Custom DDEV commands bundled with the boilerplate:

• ddev sylius-install — full Sylius installation from scratch
• ddev cc — clear caches
• ddev dist — install dependencies and build assets (Composer + Yarn)
• ddev yarn <param> — Yarn commands inside the container
• ddev security-checker — scan for known vulnerabilities
• ddev code-check — run coding standards validation
• ddev backup / ddev database-import / ddev files-import — backup and restore database and media
• ddev sylius-cleanup — reset all data (useful when re-testing install flows)
• ddev build-site / ddev rebuild-site — full or partial project rebuild

Tested on Windows 11 with WSL2 (Ubuntu 24.04), macOS Tahoe (Apple Silicon), and Linux with Docker.

Getting started#

git clone https://github.com/holas1337/ddev-sylius my-project
cd my-project
ddev start
ddev sylius-install

That's it. A few minutes later you have a running Sylius storefront with an admin panel, accessible at the DDEV-generated local URL (default https://ddev-sylius-boilerplate.ddev.site:8443).

Day-to-day workflow#

After the initial install, the typical daily commands are:

ddev start             # start the environment
ddev cc                # clear caches after config changes
ddev dist              # rebuild assets after frontend changes
ddev code-check        # check coding standards before committing
ddev backup            # snapshot database before a risky migration

For debugging, ddev xdebug on enables Xdebug, and ddev exec bin/console <command> gives direct access to the Symfony console inside the container.

What changed in 1.0.1#

The day-after release fixed things that showed up during cross-platform testing: macOS-specific adjustments for Mutagen and upload directory exclusions, MariaDB upgraded from 11.4 to 11.8, and phpMyAdmin updated to the latest version.

The repository is on GitHub: holas1337/ddev-sylius. Issues and PRs welcome.

uBlock Origin#

The essential first layer. uBlock Origin (Firefox, Chrome) blocks ads and trackers at the network level. With default filter lists enabled it already blocks most Facebook tracking pixels and social widgets on third-party sites.

Note for Chrome users: Google's Manifest V3 transition limits some uBlock Origin capabilities in Chrome. The full-featured version remains available in Firefox.

Privacy Badger#

Privacy Badger by the Electronic Frontier Foundation (Firefox, Chrome) takes a different approach: instead of using a static blocklist, it learns which trackers follow you across sites and progressively blocks them. Works well alongside uBlock Origin.

Facebook Container (Firefox only)#

Facebook Container is a Mozilla extension that isolates your Facebook session in a separate container tab. Facebook can't see your activity on other sites, and third-party Facebook widgets on other sites can't read your Facebook session cookies.

This is the most effective single extension specifically targeting Facebook's cross-site tracking — and it's built and maintained by Mozilla.

Built-in browser protections#

Both Firefox and Brave ship with enhanced tracking protection enabled by default, which blocks many known trackers including Facebook's. If you use either browser, you already have a solid baseline — the extensions above add more granular control on top.

If you use Chrome, consider switching to Firefox for better default privacy.

Before Let's Encrypt, getting a browser-trusted SSL certificate meant paying $50–$300/year to a commercial CA (Comodo, DigiCert, GoDaddy), going through manual identity verification, and configuring renewal yourself. Let's Encrypt launched in 2015, left beta in April 2016, and changed all of that: free Domain Validation certificates, automated issuance via the ACME protocol, and 90-day validity with built-in renewal tooling. For small servers and personal sites that had been running plain HTTP, this was the first practical path to HTTPS.

The official Certbot client wasn't yet packaged for Debian Jessie, so I used one of the alternative clients — a simple bash script: https://github.com/Neilpang/acme.sh

With this script you can get everything done in about 5 minutes.

Prerequisites#

• Root access to the server
• Apache running on Debian Jessie
• Domain resolving to the server's public IP
• Port 80 open (used by ACME HTTP-01 challenge to verify domain ownership)

For this guide, assume:

/root/.acme.sh/acme.sh   # where the client scripts live
mysite.com               # the domain you want a certificate for
/mnt/www/mysite.com      # the webroot for your site
/etc/apache2             # Apache installation with config files

Step 1 — Download the client#

Go to (or create) /root/.acme.sh/acme.sh and run:

git clone https://github.com/Neilpang/acme.sh

If you don't have git, download the files manually from the project page and unpack them.

Step 2 — Create a symlink for convenience#

ln -s /root/.acme.sh/ /etc/apache2/letsencrypt

Step 3 — Issue the certificate#

Make sure your site is reachable from the internet, then:

./acme.sh issue /mnt/www/mysite.com/ mysite.com

Or, if you have aliases (e.g. www.mysite.com):

./acme.sh issue /mnt/www/mysite.com/ mysite.com www.mysite.com

acme.sh places a temporary file in the webroot, Let's Encrypt fetches it to verify you control the domain, then issues the certificate. The files are saved to:

/root/.acme.sh/mysite.com/

Step 4 — Configure Apache#

Point Apache to the new certificates in your virtual host config:

SSLCACertificateFile  /etc/apache2/letsencrypt/mysite.com/ca.cer
SSLCertificateFile    /etc/apache2/letsencrypt/mysite.com/mysite.com.cer
SSLCertificateKeyFile /etc/apache2/letsencrypt/mysite.com/mysite.com.key

Then reload Apache:

service apache2 reload

Your site should now be served with a Let's Encrypt certificate.

Step 5 — Auto-renewal#

Certificates are valid for 90 days. To renew automatically, create an executable script, e.g. acme_cron:

#!/bin/sh
/root/.acme.sh/acme.sh/acme.sh cron >> /var/log/le-renew.log
service apache2 reload

Drop it in /etc/cron.daily and you're done.

The process isn't complicated — once set up, renewal is fully automatic.

This setup served well until I moved everything to Docker. The modern approach using Traefik handles Let's Encrypt automatically — no scripts, no cron, no manual config. More on that: Let's Encrypt with Docker and Traefik.

There's a cleaner way: temporary email addresses — ready in seconds, no account needed, gone after a few hours.

Guerrilla Mail#

Guerrilla Mail is the simplest option. Open the site, copy the generated address, use it. Any mail delivered there appears immediately — no refresh needed. The inbox is session-based: close the tab and it's gone.

You can also compose outgoing mail from the temporary address, which is occasionally useful for replying to confirmation emails.

Dropmail#

Dropmail goes further. It's the better choice when you need the address to last or to actually receive something reliably.

What Dropmail offers beyond a basic inbox:

• Forwarding to your real address — emails land in your normal inbox, so you don't need to keep a Dropmail tab open. Cancel forwarding at any time.
• Recovery key — save it and you can return to the same address later, even from a different device or browser session
• Two domain types — permanent domains for longer-lived addresses, rotating domains for short-term use
• Telegram bot — receive emails directly in Telegram without opening a browser
• Android app — manage temporary addresses from your phone

No registration, no premium tier needed for any of the above.

Apple Hide My Email#

If you're on Apple devices with an iCloud+ subscription (included with any paid iCloud storage plan starting at 50 GB), you already have a built-in option: Hide My Email.

It generates a unique, random address that forwards to your real inbox — permanently, until you deactivate it. No separate app, no website to visit. It's integrated directly into iOS, iPadOS, and macOS:

• Safari autofill — when you fill in an email field on a website, Safari offers to generate a hidden address automatically
• Settings → iCloud → Hide My Email — create and manage all your addresses in one place, see which ones are active, deactivate or delete any of them
• Sign in with Apple — when you use "Sign in with Apple" and choose to hide your email, Hide My Email generates the address automatically

The key difference from Guerrilla Mail and Dropmail: these addresses are permanent aliases tied to your Apple ID, not throwaway inboxes. You control them, you can disable them, and mail always arrives in your real inbox. It's the most seamless option if you're already in the Apple ecosystem — no friction, no extra tools.

The catch: it requires a paid iCloud+ plan and only works on Apple devices.

When to use which#

Use Guerrilla Mail when you just need a confirmation link and will close the tab in two minutes.

Use Dropmail when you need the address to survive beyond the browser session, or when you want emails forwarded somewhere you'll actually see them.

Use Apple Hide My Email when you're on iPhone/Mac, have iCloud+, and want zero-friction address generation built into the OS — no separate tools, permanent and manageable aliases.

What the site needed to do#

Insurance brokerage is a regulated industry. A broker's website isn't just a brochure — it needs to communicate regulatory status (KNF licence number, professional liability insurance), distinguish the firm from agents (a broker represents the client, not the insurer), and build enough trust that a potential corporate client picks up the phone.

Alfa Consilium's service portfolio covered a wide range: D&O insurance, cargo and carrier liability (OC spedytora / OC przewoźnika), machinery breakdown, leasing brokerage, factoring, receivables management, and risk management with on-site audits. Each service area needed a clear, standalone description — not a wall of text, but enough substance for a decision-maker to understand scope and contact the team.

Design and implementation#

The site was designed with a clean corporate aesthetic: structured layout, clear service navigation, and contact information accessible from every page. Financial sector clients — logistics companies, manufacturers, fleet operators — expect a professional presentation, not a startup landing page.

Implementation was on WordPress with a custom PHP theme built from scratch — no off-the-shelf theme. The template handled three responsive breakpoints: desktop, tablet, and mobile. Responsive design was still far from standard practice in Poland in 2016; most small corporate sites were still fixed-width.

WordPress was the right choice for the client: the content team could update service descriptions and news without developer involvement, and the admin interface required no training.

What was delivered#

• Full visual design (desktop + tablet + mobile)
• Custom WordPress theme in PHP
• Service pages for all insurance and financial product lines
• Contact section with regulatory information (KNF supervision details, professional liability insurance)
• Responsive layout across all three breakpoints

Screenshot from the live site.

The company continues to operate — the original .pl domain now redirects to alfaconsilium.eu.

In 2015, single-board computers were becoming a practical option for a low-power always-on home server. The Raspberry Pi 2 was the obvious choice, but the Banana Pi offered something the Pi couldn't: a SATA port. For a server that would store media files and run backups, a real hard drive was a non-negotiable advantage over SD card storage.

Hardware#

The Banana Pi is built around the Allwinner A20 SoC — a dual-core ARM Cortex-A7 running at 1 GHz. Key specs that made it the right choice:

• CPU: Allwinner A20, 2× 1 GHz (Cortex-A7)
• RAM: 1 GB DDR3
• Gigabit Ethernet (vs 100 Mbit on the RPi 2)
• SATA port — the deciding factor. A SATA HDD is faster, more reliable, and orders of magnitude larger than any SD card

The setup: Banana Pi in a case, 2.5" SATA drive for storage, a 4 GB USB stick for backups.

What it ran#

Running Bananian — a Banana Pi-specific Debian distribution (note: discontinued in 2016, superseded by Armbian) — the server handled:

• Media server (minidlna — stream music and video to TV over DLNA without booting a full PC)
• SSH (headless remote management from anywhere)
• VPN (OpenVPN — safe use of public Wi-Fi, access to the home network remotely)
• VNC (TightVNC — graphical session when needed, e.g. for jDownloader)
• Web server (LAMP stack — this site ran on it, plus a few personal projects)
• Backups (bash scripts on cron, no extra tooling)
• Downloads (aria2 and curl for command-line; jDownloader in graphical mode when needed)

In practice#

Everything ran fast, reliably, and stable around the clock. The real benefit was power consumption: the Banana Pi draws around 4–8 W under typical load. Spinning up an old Core 2 Duo desktop (65 W TDP, plus the rest of the system) just to listen to music made no sense. An hour on the old machine equalled a full day on the Banana Pi.

Banana Pi in its case with a SATA drive and an old 4 GB USB stick for backups.

Banana Pi from the admin console side.

If you have basic Linux admin skills and want a low-power always-on server, the Debian ecosystem gives you everything you need.

This setup eventually reached its limits. In 2026 I replaced it with a Raspberry Pi 5 with NVMe storage and full Docker containerization. Read about it: Raspberry Pi 5: Migration to NVMe and service containerization.

Why a rebuild, not a patch#

The old design used two separate templates: a full desktop layout and a mobile skin served via user-agent detection. That approach had worked in 2008, but by 2015 it had become a maintenance liability — any content or style change needed to be applied twice, and the growing variety of device sizes made the binary desktop/mobile split increasingly inadequate. Tablets, phablets, and high-DPI screens all fell into awkward territory.

The decision was a full rebuild rather than trying to bolt responsiveness onto the old codebase. Starting from scratch meant cleaner SCSS, a proper semantic HTML structure, and no legacy hacks to carry forward.

Technical implementation#

The theme was custom-built on WordPress — no off-the-shelf theme, no page builder. The implementation covered:

• PHP templates following the WordPress template hierarchy (single.php, archive.php, page.php, functions.php)
• SCSS compiled to a single stylesheet — variables for colors, spacing, and breakpoints
• Fluid grid with three breakpoints: mobile, tablet, and desktop
• Single codebase — one set of templates, one stylesheet, all screen sizes handled through CSS media queries

What else changed at the same time#

The rebuild coincided with a server migration — the site moved to a self-hosted Banana Pi running Debian 24/7. That setup is documented separately.

What came after#

The responsive rebuild worked well and the design held up for several years. But working with WordPress increasingly meant fighting its abstractions rather than building with them — the plugin ecosystem, the PHP templating constraints, the deployment story. In 2026 I replaced it entirely — the full story is in Why I left WordPress.

On 27 July 2015 at 18:00, the first PHPers meetup in Toruń took place at Krajina Piva, Rynek Nowomiejski 8. I co-organised it together with Szymon Skowroński. Starting a new city chapter meant establishing a regular meeting place for PHP developers in the region — and 57 people attended, with another 34 marking themselves as interested.

Talks#

Three talks covered a range of PHP topics:

• Leszek Prabucki — Podstawy programowania obiektywnego w PHP (Basics of objective programming in PHP)
• Łukasz Lubosz — Blackfire — inteligentny profiler (Blackfire — the intelligent profiler)
• Leszek Krupiński — Co PHP? zepsuje w Twoim kodzie (What will PHP? break in your code)

Sponsors#

The event was made possible by support from Cocoders, ecenter.pl, and Krajina Piva, who hosted us.

Why community matters#

Organising events like this is something I value alongside day-to-day development work. Building a local developer network means better knowledge sharing, stronger connections between developers in the region, and a more active local tech scene. The 91 total RSVPs for a first-ever meetup in Toruń showed the appetite was there.

The full event details are on Facebook.

What the site needed to do#

The site had to communicate the full scope of what Bifor offered and give visitors a reason to come in. The navigation reflected that breadth: Aktualności (News), O nas (About), Kuchnia (Kitchen), Kultura (Culture), Sport, Napoje i Alko (Drinks), and Kontakt. A prominent table reservation CTA with a phone number appeared on every page, and a Facebook Like Box kept the social presence integrated with the site.

Implementation#

The site was built on WordPress with a custom PHP theme, implemented from a designer-provided mockup — no off-the-shelf template. The implementation covered:

• Three responsive breakpoints — desktop, tablet, and mobile — with the layout adapting at each
• PHP template files following the WordPress template hierarchy
• CMS-managed content so the client could update news, events, the menu, and opening hours independently
• Facebook integration via the Like Box widget

My role was converting the designer's static mockup into a fully functional WordPress theme. The visual identity — dark colour scheme, bold typography, the B!FOR logo — came from the design brief; the job was pixel-accurate implementation with clean, maintainable code.

Site no longer live.

What the client does#

Fabryka Kształtów produces advertising and promotional materials: display lettering, lightboxes, plexi shelves and stands, decorative wall elements, car wrapping, and custom 3D forms and reliefs. On the services side, they run CNC/3D cutting equipment (working area 2000×3000×200 mm) for aluminium, soft metals, dibond, alucobond, plastics (plexi, PCV, HIPS), plywood, and MDF — plus a cutting plotter (up to 1250 mm wide) for standard, flex, velour, car, and magnetic vinyls.

The site#

The structure was deliberately minimal — three pages matching the questions a potential client would ask:

• Kim jesteśmy? (Who are we?) — company background
• Co robimy? (What do we do?) — full service and production list
• Jak nas znaleźć? (How to find us?) — contact and address

The choice to go static was deliberate: a business card site with no dynamic content needs no CMS. Pure HTML/CSS/JS keeps the site fast, cheap to host, and free of maintenance overhead.

Two breakpoints — desktop and mobile — covered the use case without overengineering. In 2014, three-breakpoint RWD was not yet the default expectation for a small business site like this.

Desktop version.

Mobile version.

The design was completed but never went into production.

What the company does#

EKO TREND INWEST builds and sells single-family homes on their own plots in the Warsaw area. Beyond new builds, they also handle construction and renovation of residential, utility, and industrial buildings, and offer credit advisory services for clients financing investments.

Their homepage positioned the company on quality and reliability: own workforce, vetted subcontractors, premium materials from established suppliers, price guarantees backed by contract. Indicative pricing for traditional single-family builds started at 350 PLN/m² for shell construction (2–3 months), developer standard at 5–6 months, and turnkey at around 8 months.

The site#

The site had eight sections reflecting the full scope of what a prospective buyer would want to know: Osiedle (the housing estate), Lokalizacja (location), Plan osiedla (estate plan), Technologia wykonania (construction technology), Galeria / Realizacje (gallery and completed projects), Doradztwo kredytowe (credit advisory), and Kontakt. The dark charcoal and green colour scheme matched the "EKO" branding, with property photography throughout.

The CMS choice — QuickCMS — gave the client a lightweight, editable back-end without the overhead of WordPress. My role covered the custom theme and full implementation.

Site no longer live — archived snapshot on Wayback Machine.

What the company does#

HR Management's differentiator was the breadth and depth of integrated services: insurance advisory, legal advisory through an affiliated law firm (kancelaria radców prawnych), insurance brokerage, claims handling (representing clients before insurance companies and in court), and consulting for risk assessment. As CEO dr Tomasz Kamiński put it — that combination of lawyers, insurance brokers, and consultants under one roof was rare on the Polish insurance and legal market at the time.

The news section covered topics like D&O (Directors & Officers) coverage for company boards, construction insurance case studies, and medical events insurance. By 2013, the company had expanded to the German market.

The site#

The homepage featured a service grid of six tiles — O nas, Doradztwo prawne, Consulting, Pośrednictwo ubezpieczeniowe, Likwidacja szkód, Dokumenty — alongside a news feed with dated articles. Navigation was minimal: Strona główna, Aktualności, O nas, Kontakt. White and grey background with orange/blue accents, matching the corporate identity.

The two-phase approach worked well: the business card site gave the client an immediate online presence while the full CMS-backed site was designed and built. QuickCMS gave the client full editorial control over news and content.

Site still live at hr.com.pl.

The placeholder approach#

The scope was deliberate and minimal: a single-page HTML/CSS/JS site with a four-panel slideshow — fast to build and fast to load. No CMS, no backend, no moving parts to maintain. The goal was to establish an online presence quickly while the proper site was being built.

What the slides showed#

The four slides covered: the company logo and legal details ("Strona w przebudowie" — site under construction), the tagline ("ROZWIJAMY SIĘ Z WAMI i dla Was"), legal advisory and consulting contacts, and insurance brokerage and claims handling contacts.

Archive screenshot of all four slideshow panels.

Replaced two months later by the full QuickCMS site: HR Management — full site.

What the venue offers#

Polufka positioned itself as the go-to spot in the student district: a warm, atmospheric pub for watching sport, playing board games, and meeting over a beer. The site reflected that character — dark wood-paneled design, a playful tone throughout the navigation (Po Piwku?, Po Lufte?), and a blog-style news and events section keeping regulars up to date on upcoming screenings and events. Full navigation: O nas, Po Piwku?, Po Lufte?, Napoje, Przekąski, Galeria, Kontakt.

The sidebar featured a calendar, an upcoming events widget, partner links, and a Facebook Like Box — the standard mix for a venue with an active community of regulars.

Mobile handling in 2011#

The notable aspect of this project was the mobile handling: the site shipped with both a full desktop version and a dedicated mobile version, served via user-agent detection. This was the standard approach in 2011 — Ethan Marcotte had published the responsive web design concept just a year earlier, and separate mobile templates were still common practice. The two-template setup meant the mobile experience could be tailored specifically to small screens without compromising the desktop layout.

The original site is archived on Wayback Machine. Polufka is still active — now at a new location in Wrzeszcz with a new site.