DEV Community: Adele Beitvashahi

Deploy your own database as a remote backend service in less than an hour

Adele Beitvashahi — Mon, 19 Oct 2026 00:26:05 +0000

Context

Every once in a while I have to stand up a new backend/DB. I used to just use Supabase, but I don't like the idea of not owning my data, and I like my bill being the same number every month.

I personally love Pocketbase for this. It's ✨one binary✨ with a database (SQLite), auth, file storage, a REST API and an admin dashboard baked in. No install wizard, no 14 microservices, no YAML cathedral. It's what I reach for whenever a project needs a small, self-contained backend. If you want to compare other options, here are some other alternatives you could check out.

Challenge

I've now set this up for a handful of projects, and every single time I had to rediscover the steps like a goldfish with a keyboard. So this is the cheat sheet.

What we're building

By the end, requests will flow like this:

client (any app that calls your backend) → Reverse proxy tool (nginx) (HTTPS, on a server) → Docker container (PocketBase) → volume (your database)

The game plan (Agile style)

Run PocketBase in a local dev environment
Put it behind nginx
Containerize it and keep it behind the local nginx
Put nginx and the container on a VPS (remote env), with a domain and HTTPS
Introduce a container registry for versioning our image (in our case GHCR)
Automate the deploys with GitHub Actions or another CI/CD tool

What you'll need

Here's the stack I'm using, and what each piece is called in case you want to swap in your own:

A backend/database: I'll be using PocketBase, an open source backend in a single executable with SQLite built in
A container platform: I'm using Docker (and Docker Compose) because it's what I like to use the most
A reverse proxy: it routes incoming requests to the right app, handles HTTPS, and enforces limits. I'll be using nginx
Version control: Git, hosted on GitHub, because I like GitHub
A container registry: a place to store our built Docker images. I use GHCR (GitHub Container Registry)
A CI/CD tool: continuous integration/continuous delivery, the thing that builds and deploys for you on every push. I use GitHub Actions
A remote environment: a VPS (virtual private server) to run it all on. I love DigitalOcean droplets
A domain/subdomain for making the DB accessible on the internet
Optional A health check monitor: a service that keeps pinging PocketBase's health endpoint and alerts you (or triggers a rollback) when it stops responding

and last but not least, a handy dandy terminal with basic knowledge of SSH.

BONUS: some music to help you lock in and time yourself. If you don't finish this tutorial within an hour, I'll personally refund you.

Everything in angle brackets like <username> or <website-url> is a placeholder for your own value.

1. PocketBase, locally

Nothing fancy yet. We want PocketBase running on your machine so you know what we're about to ship. Here's how:

# grab the binary for your OS/arch from https://github.com/pocketbase/pocketbase/releases
# (put it in a `pocketbase/` folder in your project)
cd pocketbase

# run the migrations, then start the server
PB_ENV=dev ./pocketbase migrate up
PB_ENV=dev ./pocketbase serve

# create yourself a superuser
./pocketbase superuser upsert dev-admin@example.com change-me-locally

If you're on Windows that's pocketbase.exe.

The admin dashboard lives at http://127.0.0.1:8090/_/.

You don't actually need PB_ENV (it isn't a PocketBase thing, just an environment variable I made up) or cross-env (a tiny tool that makes PB_ENV=dev work in any shell, Windows included), but they're useful for one very specific thing. Locally I want a user to log in with so I'm not creating one by hand every time I wipe my database. But I definitely don't want that user existing in production. So let's make a migration that only runs when PB_ENV=dev.

./pocketbase migrate create dev_user

// pb_migrations/<timestamp>_dev_user.js
/// <reference path="../pb_data/types.d.ts" />
migrate((app) => {
  // bail out unless we are in dev
  if ($os.getenv("PB_ENV") !== "dev") return;

  let existing;
  const DEV_EMAIL = "dev@example.com";
  const DEV_PASS = "change-me-locally";
  try {
    existing = app.findFirstRecordByData("users", "email", DEV_EMAIL);
  } catch (e) {
    existing = null;
  }
  if (existing) return;

  const record = new Record(app.findCollectionByNameOrId("users"));
  record.set("email", DEV_EMAIL);
  record.set("password", DEV_PASS);
  record.set("verified", true);
  app.save(record);
}, (app) => {
  // same guard on the way down
  if ($os.getenv("PB_ENV") !== "dev") return;

  let existing;
  try {
    existing = app.findFirstRecordByData("users", "email", "dev@example.com");
  } catch (e) {
    existing = null;
  }
  if (existing) app.delete(existing);
})

That PB_ENV check is the whole trick. In production the migration runs, shrugs, and does nothing.

Here's what we've achieved so far:

✅ PocketBase running locally
✅ a superuser and a dev-only user
✅ migrations that know which environment they're in

2. Put it behind nginx

Right now you're talking to PocketBase directly on port 8090. That's fine on your laptop, but it's not what you want facing the internet. Before we touch the server, let's get used to the setup we'll use there.

What is nginx doing here? It's a reverse proxy. It sits in front of PocketBase, accepts the incoming requests, and forwards them to it. That gives us a few things:

HTTPS. nginx handles the TLS certificate so PocketBase doesn't have to
One front door for many apps. Several apps can share one server and one port 443, routed by domain name
Guard rails. Rate limits and a max upload size, before a request ever reaches PocketBase
Privacy. The app itself only listens on localhost and can't be reached directly from the internet

What else could you use?

Caddy is simpler, and gets and renews HTTPS certificates automatically
Traefik is built for containers and configures itself from Docker labels
PocketBase can also serve HTTPS by itself if you hand it a domain, which is the least moving parts if it's the only thing on the box

Why nginx then? For me it's familiarity and it gives me everything I need at the moment out of the box; Rate limiting and upload limits in one config file. If you're starting from scratch with a single app, Caddy is a perfectly good answer as well.

Install nginx (brew install nginx, sudo apt install nginx, or the zip from nginx.org on Windows) and add this server block to your config. Where it goes depends on your OS: conf.d/, sites-enabled/, or inside http {} in nginx.conf.

# local dev: nginx listens on 8080 and forwards to PocketBase on 8090
server {
    listen 8080;
    server_name localhost;

    # max upload size, i.e. maxSelect:20 * maxSize:10MB per request
    client_max_body_size 250m;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    location / {
        proxy_pass http://127.0.0.1:8090;
    }
}

nginx -t          # check the config
nginx -s reload   # (or start nginx if it isn't running yet)

Now http://localhost:8080/_/ shows the same dashboard, but through nginx. If you plan to use PocketBase's realtime subscriptions, double check PocketBase's docs for the extra nginx proxy settings they recommend.

Later we'll add a rate limit for any collection that strangers are allowed to write to. For now, one thing to take away: nginx doesn't care what's behind it, as long as something answers on the port you give it. Which brings us to the next step.

3. Put PocketBase in Docker Compose, behind the same nginx

Now we put PocketBase in a box, a container, 🐳

What does Docker give us? It's a container platform: it packages an app and everything it needs into an image, and runs that image as an isolated container. That makes it easy to set up the same environment across platforms/machines with a single command. To update you just pull the latest image, rollback is the same with an older image, and your data stays safe in a volume.

What else could you use?

Run the binary directly under systemd. Fewer layers, totally valid for a hobby project, but you're updating and wiring it up by hand every time
Podman, a Docker-compatible alternative that runs without a background daemon
Kubernetes (or a lighter orchestrator like Docker Swarm or Nomad). They run and scale containers across many servers, which is way more than one small PocketBase on one box needs, but good to know they exist for when you outgrow this
A managed PocketBase host, or a PaaS with persistent disks, if you'd rather not run a server at all

Here's the Dockerfile. Notice we only copy in pb_hooks and pb_migrations, the code, not the data. Your actual database lives in a volume.

# pocketbase/Dockerfile
FROM alpine:3.20

# pin whatever version you tested against, bump it on purpose
ARG PB_VERSION=0.40.2

RUN apk add --no-cache unzip ca-certificates curl

WORKDIR /pb

RUN curl -L -o pb.zip https://github.com/pocketbase/pocketbase/releases/download/v${PB_VERSION}/pocketbase_${PB_VERSION}_linux_amd64.zip \
    && unzip pb.zip -d /pb/ \
    && rm pb.zip \
    && chmod +x /pb/pocketbase

COPY pb_hooks /pb/pb_hooks
COPY pb_migrations /pb/pb_migrations

EXPOSE 8090

CMD ["/pb/pocketbase", "serve", "--http=0.0.0.0:8090"]

Heads up, those two COPY lines will fail the build if the folders don't exist. That's why running migrate up locally first matters, it makes sure pb_migrations/ is there so the image can actually be built.

And the compose file:

# pocketbase/docker-compose.yml
services:
  pocketbase:
    build: .
    restart: unless-stopped
    ports:
      - "127.0.0.1:8091:8090"
    environment:
      - PB_ENV=${PB_ENV:-production}
    volumes:
      - pb_data:/pb/pb_data

volumes:
  pb_data:

A few small details doing big work here:

127.0.0.1:8091:8090 reads as host-ip:host-port:container-port, and the two port numbers are different on purpose so you can see which is which:
- 8090 is the port PocketBase listens on inside the container. It's fixed by the Dockerfile and nobody outside the container can see it
- 8091 is the port Docker listens on on the machine itself (the host). It passes whatever arrives there into the container's 8090. This is the port nginx forwards to, that's the proxy_pass. The public internet never calls 8091, it talks to nginx
- 8090 is the default and you could have both of them ast 8090 or use any free port.
That 127.0.0.1 (instead of 0.0.0.0) means the container is only reachable through nginx and not directly from the internet
PB_ENV=${PB_ENV:-production} defaults to production, so you have to ask for dev on purpose. Our dev-only migration stays asleep unless you say otherwise
the pb_data volume, so recreating the container doesn't delete your database

You can stop the binary from step 1 now (Ctrl+C). Start the container in dev mode, then point nginx at the new port by changing proxy_pass to http://127.0.0.1:8091 and reloading:

cd pocketbase
PB_ENV=dev docker compose up -d --build
# PowerShell: $env:PB_ENV="dev"; docker compose up -d --build
nginx -s reload

http://localhost:8080/_/ works again, same nginx, different thing behind it. The container starts with an empty database, so run the superuser command again:

docker compose exec pocketbase /pb/pocketbase superuser upsert dev-admin@example.com change-me-locally

Here's what we've achieved so far:

✅ PocketBase running locally, directly and in a container
✅ nginx in front of it

4. Put it on a VPS

Same two pieces, nginx and the compose file, but this time on a server on the internet.

Why a VPS? I get a real Linux box with full control, a flat monthly price, and a place for several small apps. PocketBase wants a persistent disk, and a VPS has one.

Any provider works. A few to look at:

DigitalOcean (Droplets)
AWS (Lightsail or EC2)
Microsoft Azure (Virtual Machines)
Google Cloud (Compute Engine)
Hetzner (Cloud servers)

Here's the order, and the order matters:

DNS first

Add an A record pointing your subdomain (api.yourdomain.com, or anything you like) at the server's IP. DNS takes a while to propagate and we need it ready for HTTPS, so do it now and do the rest while it settles.

Prep the server

apt update && apt install -y nginx certbot python3-certbot-nginx

Then create a dedicated user for deploys, don't deploy as root:

sudo adduser <username>
sudo mkdir -p /opt/<dirname>
sudo chown -R <username>:<username> /opt/<dirname>
# the user needs docker access
sudo usermod -aG docker <username>
# somewhere for the deploy key to live
sudo -u <username> mkdir -p -m 700 /home/<username>/.ssh

And not on the server, on your own machine, make a deploy key and give the server the public half:

# make a dedicated deploy key
ssh-keygen -t ed25519 -C <username> -f ~/.ssh/<keyname> -N "<passphrase>"

# log in as root once and copy the public key over
ssh root@<vps-ip> "cat >> /home/<username>/.ssh/authorized_keys" < ~/.ssh/<keyname>.pub

# or, if you want to prepend restrictions to the key
sed 's/^/no-port-forwarding,no-agent-forwarding /' ~/.ssh/<keyname>.pub | ssh root@<vps-ip> "cat >> /home/<username>/.ssh/authorized_keys"

# make sure the new user can actually log in
ssh <username>@<vps-ip> -i ~/.ssh/<keyname>

A dedicated deploy key is cleaner than reusing your personal one, if it leaks you revoke that one key and nothing else.

Get the files there and start it

For now we'll build the image right on the server. Run this from your pocketbase/ folder (we're sending the code, not your local data):

scp -r Dockerfile docker-compose.yml pb_hooks pb_migrations <username>@<vps-ip>:/opt/<dirname>/
ssh <username>@<vps-ip> -i ~/.ssh/<keyname> "cd /opt/<dirname> && docker compose up -d --build"

No PB_ENV this time, so it defaults to production and the dev user is never created.

The server's nginx

Same idea as before, with three upgrades: your real domain, the production port, and a rate limit.

# throttle public write endpoints to curb spam
limit_req_zone $binary_remote_addr zone=<zone-name>:10m rate=5r/m;

server {
    listen 80;
    server_name <website-url>;

    # max upload size, i.e. maxSelect:20 * maxSize:10MB per request
    client_max_body_size 250m;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # any collection with a public (unauthenticated) createRule
    location = /api/collections/<collection>/records {
        limit_req zone=<zone-name> burst=3 nodelay;
        proxy_pass http://127.0.0.1:8091;
    }

    location / {
        proxy_pass http://127.0.0.1:8091;
    }
}

That limit_req block is for any collection where you let strangers create records, like a contact form. If the rule is public, the internet will find it. Rate limit it.

Copy it over, enable it, and issue a free HTTPS certificate. Writing to /etc/nginx and running certbot needs root, so use your root login here. Your deploy user shouldn't need that power, and I'd keep it that way.

scp nginx-<website-url>.conf root@<vps-ip>:/etc/nginx/sites-available/<website-url>
ssh root@<vps-ip> "ln -s /etc/nginx/sites-available/<website-url> /etc/nginx/sites-enabled/ && nginx -t && systemctl reload nginx"
# once DNS has propagated
ssh root@<vps-ip> "certbot --nginx -d <website-url>"

Certbot rewrites the site file in place and adds the 443 block plus an 80 → 443 redirect.

Your production superuser

The dev account was never created here (thanks PB_ENV), so nobody can log in yet:

ssh <username>@<vps-ip> -i ~/.ssh/<keyname>
cd /opt/<dirname>
# confirm the container is running
docker compose ps
# create the real superuser with a real password
docker compose exec pocketbase /pb/pocketbase superuser upsert <superuser-email> <strong-password>

Visit https://<website-url>/_/ and log in.

Here's what we've achieved so far:

✅ PocketBase running on a server, in a container, only reachable through nginx
✅ a deploy user with its own key
✅ a real superuser and no dev account in production

5. A container registry

Right now the server builds the image itself. It works, but every deploy means sending files over and building on a small machine, and there's no clean record of which version is running.

What's a container registry? It's a place to store built Docker images, with tags. Instead of building on the server, we build once somewhere else, push the image to the registry with a version tag, and the server just pulls that exact image. That gets us:

Faster, lighter deploys. The server only downloads, it never builds
Versioning. We tag each image with the git commit that produced it, so you always know what's running and can roll back by pulling an older tag
The same image everywhere. What you tested is what you deploy

What else could you use?

Docker Hub, the default and the most common, but anonymous pulls are rate limited
A cloud provider's own registry (AWS ECR, DigitalOcean Container Registry, and so on), good if you already live there, but another service to set up and pay attention to
Running your own registry, which is one more server to look after

Why GHCR? GitHub Container Registry (ghcr.io) lives right next to the code. Our deploy will run on GitHub Actions anyway, and Actions can log in to GHCR with the token it already has, no extra account and no extra secret to manage.

Your compose file changes in one place: swap build: . for an image: line. This is the file that lives on the server from now on:

# pocketbase/docker-compose.yml
services:
  pocketbase:
    image: ghcr.io/<github-user>/<dirname>:${IMAGE_TAG:-latest}
    restart: unless-stopped
    ports:
      - "127.0.0.1:8091:8090"
    environment:
      - PB_ENV=production
    volumes:
      - pb_data:/pb/pb_data

volumes:
  pb_data:

Two notes. Image names on GHCR have to be lowercase. And ${IMAGE_TAG:-latest} means "use this tag, or latest if I didn't give one", which is how a deploy picks a specific version.

6. Automate it with GitHub Actions

You could build and push by hand, but we've built all this so we can just push to main and let the computer handle it automatically (AI, ladies and gentlemen).

Here's the whole pipeline at a glance:

First, give GitHub the key it needs. In your repo settings, add these as Actions secrets:

VPS_HOST = the VPS's IP
VPS_USER = <username>
VPS_SSH_KEY = the private key that matches the authorized key on the VPS
VPS_SSH_PASSPHRASE = the passphrase, only if you set one

Then the workflow. It builds the image, pushes it to GHCR, copies the compose file to the server, pulls and restarts, and waits for PocketBase to say it's healthy.

# .github/workflows/deploy-pocketbase.yml
name: Deploy PocketBase

on:
  push:
    branches: [main]
    paths:
      - "pocketbase/**"
      - ".github/workflows/deploy-pocketbase.yml"
  workflow_dispatch: {}

permissions:
  contents: read
  packages: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v6
        with:
          context: ./pocketbase
          file: ./pocketbase/Dockerfile
          push: true
          tags: |
            ghcr.io/<github-user>/<dirname>:${{ github.sha }}
            ghcr.io/<github-user>/<dirname>:latest

      - name: Copy compose file to VPS
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          source: "pocketbase/docker-compose.yml"
          target: "/opt/<dirname>/"
          strip_components: 1

      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1.0.3
        env:
          GHCR_ACTOR: ${{ github.actor }}
          GHCR_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          IMAGE_TAG: ${{ github.sha }}
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          envs: GHCR_ACTOR,GHCR_TOKEN,IMAGE_TAG
          script: |
            echo "$GHCR_TOKEN" | docker login ghcr.io -u "$GHCR_ACTOR" --password-stdin
            cd /opt/<dirname>
            docker compose pull pocketbase
            docker compose up -d

      - name: Health check
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            for i in $(seq 1 30); do
              if curl -sf http://127.0.0.1:8091/api/health > /dev/null 2>&1; then
                echo "Health check passed"
                exit 0
              fi
              echo "Attempt $i/30 - waiting..."
              sleep 2
            done
            echo "Health check failed after 30 attempts"
            exit 1

Because of workflow_dispatch, you can also trigger it by hand from the Actions tab, no merging required. Very handy for the "I changed nothing, please just try again" moments.

Push to main and watch the Actions tab do its thing. Every deploy is now tagged with its commit, and that's your rollback button.

Finishing touches

Point your frontend at it. For me that's an environment variable in Vercel:

NEXT_PUBLIC_POCKETBASE_URL=https://<website-url>

Redeploy the frontend, and that's it.

For the days when something is off, here's my "turn it off and on again" toolkit:

ssh <username>@<vps-ip> -i ~/.ssh/<keyname>
cd /opt/<dirname>
docker compose ps                          # status
docker compose logs -f                     # tail the logs
docker compose up -d                       # start/restart (does NOT pull a new image)
docker compose pull && docker compose up -d   # get the latest image, then restart
docker compose exec pocketbase sh          # shell into the running container

What I left out, because it's beyond a one hour setup but you'll want it soon: backups of the pb_data volume, a firewall that only allows SSH, HTTP and HTTPS, and some kind of uptime monitoring.

Here's the whole journey:

✅ PocketBase running locally with a dev-only user
✅ nginx in front of it, and why
✅ a container that ships your code and keeps your data in a volume
✅ a VPS with a domain, HTTPS and rate limiting
✅ a registry so every deploy has a version
✅ a pipeline that deploys on every push to main

And there you have it! This was how to deploy your own PocketBase backend to a remote environment, in less than an hour (or something like that).

P.S. if you only need this for a hobby project, you could skip the pipeline and the registry and stop at step 4. It works fine, you'll just be doing the deploys by hand.

If you have any comments, questions, or concerns, please keep them to yourself.

All typos are on purpose.

Resources

Choosing a video hosting provider for hobby projects

Adele Beitvashahi — Mon, 30 Mar 2026 02:06:36 +0000

Something embarrassing happened to me recently. I was at a networking event and I was excited to show someone my website and passion project Jamroom. As soon as I pulled them up, I remembered how long it'd been since I created these projects. The UI/UX I'd built a couple of years ago felt stale, and there were unpolished edges I never went back to.

So I spent last weekend to revamp the UI, rethink some of the UX, and I even finally recorded a demo for Jamroom¹ to showcase on my website!

A new challenge I was presented with then was where to host the demo video. In the past I'd always reach for the quick and dirty solutions like hosting on Vimeo, YouTube's unlisted videos, or GitHub even. This time I decided it was time for change, I wanted to host my assets on my own infra. To do this I came up with two requirements:
1) The solution needs to be free/dirt cheap
2) The setup can't take more than a few minutes, time is money!

Did some research and landed on Cloudflare R2, they offer a generous free tier. But mid-onboarding I realized in order to use the free tier, I'd have to either:
1) Switch my DNS provider to Cloudflare, having to migrate all my DNS records, which would absolutely take more than a few minutes.
2) Setup URL pre-signing on my backend to provide public access to the videos in my private bucket. Which would be unnecessary work for my needs at this time.

So I kept digging and voila! Enter Vercel Blob storage, their free tier offers free public access to your assets, albeit it's very limited. But it's good enough for now! There'll come a time when I'll have to finally setup the URL pre-signing to take advantage of the more generous free services out there, but till then I can invest my time in more pressing projects.

Here are my realistic options, optimizing for ease of setup/use and cost.

provider	cheapest tier	tier limits	public URL access
Backblaze B2	forever free	10GB storage, unlimited free egress, 1M writes + 10M reads/mo	Yes—public buckets support direct URLs , but cannot map custom domain without Cloudflare workaround
Supabase Storage	free forever	1GB file storage, 5GB bandwidth, 50K MAUs	Yes—public buckets provide direct asset URLs without auth
DigitalOcean Spaces	$5/month	250GB storage, 1TB outbound transfer	Yes—files can be set to public permissions with direct URLs
Vercel Blob	free (Hobby)	1GB storage, 10GB Blob Data Transfer/month	Yes—native public access with permanent URLs
AWS S3	free 12mo	5GB storage, 20K GET + 2K PUT requests/month, 100GB data transfer out	Yes via public bucket or presigned URLs

AI Resume Filters Can't Read Between the Lines

Adele Beitvashahi — Wed, 18 Mar 2026 21:33:29 +0000

Picture this:

A Resume bullet says: "built X system that served 1M+ users at "
A job description says: "implement metrics, logging, and dashboards."

The AI sees no overlap and disqualifies the candidate. But any engineer who shipped to a million users (heck anyone who has built anything for any business) has absolutely built observability infrastructure, they just didn't waste resume space saying so. Sometimes they handcrafted the dashboards, sometimes they used already present tooling like Mixpanel and other observability platforms with built in dashboarding capabilities. The point is businesses require observability period.

Observability is just one example. Testing, code review, documentation, incident response, none of it makes the resume because those are all implementation details of the role, the meat and the potatoes are the ✨results✨

Of course that's not to say those implementation details are unimportant, but time and place for everything, they're meant to be communicated verbally during the interview. That's what interviews are for.

Resumes are meant to showcase highlights of your career through story telling focused on impactful work, not serve as a laundry list of every single task you've done. That'd turn it into an unsustainably large alphabet soup. A soup so large even the AI systems ingesting it would lose their appetite.

Of course I don't believe we'll ever give up AI in recruiting or any other industry. The AI isn't the problem. The prompt behind it is, and that's on whoever built the filtering tool. A productive step may be to work towards more intelligent system prompts that do more than just keyword matching. That's what LLMs are for after all. Here's an example of a system prompt designed to infer implied skills from context clues. Things like treating "served 1M+ users" as an observability signal, or treating quantified improvements as evidence of instrumentation.

Disclaimer: this is illustrative, not a comprehensive solution.

You are a resume intelligence system. Your job is to evaluate a candidate's 
true qualifications by reading between the lines, not just scanning for keywords.

Experienced engineers don't list every task they performed. They tell a story 
of impact. Your job is to understand what that story implies.

When evaluating a resume against a job description, consider what the candidate 
almost certainly did but didn't write down. A system serving millions of users 
implies observability. Quantified improvements imply instrumentation. Enterprise 
experience implies process. Real-time features imply distributed systems thinking.
Startup experience implies ownership and autonomy.

Use context clues from company size, scale, tech stack, and career trajectory 
to infer unstated but implied competencies. Distinguish between a real skill gap 
and a resume brevity gap. Flag the latter for interview validation rather than 
automatic disqualification.

The best resumes are highlight reels, not task logs. They're narrative-driven 
stories of impact, not exhaustive records of everything someone has ever done. 
Don't penalize candidates for writing a good one.

How to use Filters in PrimeReact DataTables

Adele Beitvashahi — Mon, 09 Sep 2024 20:07:34 +0000

[UPDATE]: I've made a comprehensive demo on blitzstack which goes in depth on the different filtering scenarios that are neglected in the primereact docs. I'll update this article into a full writeup when I get the chance but for now that should serve all your filtering needs and then some! check it out

[EDIT]: insightful github discussion

I wrote a very long post then decided an image is worth a thousand words, so there you go.

Although the images uploaded to dev.to get downscaled so maybe this one is only worth 250 words.

The aim of this post was to reduce headaches induced by things unsaid in the official docs. There was a lack of resources online for using filters with MultiSelect and Dropdown components correctly with a more-than-basic data structure setup. So I'm using this post as a resource for future me and anyone else that might find this useful

If you look at the top left of that image there is a string[] that holds fruit names, that's because you can also use string[] instead of Object[] for the filter item list. I didn't expand on it because the official docs do a good enough job doing it.

I tried to cover things the docs failed to cover.

How to setup dev containers in windows

Adele Beitvashahi — Wed, 28 Aug 2024 02:41:52 +0000

If you are going to work with dev containers in Windows you need to realize that they will break HMR (hot module reload) and increase build time unless you put your code inside WSL instead of the windows filesystem.

How Dev Containers Work in Windows

Dev containers use Docker, which relies on WSL. When you spin up a dev container, VSCode starts a docker container in WSL, and mounts the files from windows (if they are stored there). This means changes have to cross the WSL-Windows environment. This tends to break HMR, because HMR relies on file change API of the host env, and the filesystem events don't travel well between different host environments.

Correct setup for dev containers in Windows

1. Dev container setup in WSL

Install Visual Studio Code
Enable WSL 2 by following the WSL 2 installation guide
Install Ubuntu (or your preferred Linux distribution) from the Microsoft store
Install Docker Desktop Stable 2.3.0.2
Finally enable Docker support in WSL 2 distros.
Follow all the directions here to finish setup.

2. Clone repo inside the WSL filesystem

Now you should be able to do yarn && yarn dev inside WSL and HMR should work.

Connect to Azure VM w/SSH Through Azure CLI

Adele Beitvashahi — Mon, 12 Aug 2024 20:24:51 +0000

1. Create your VM

2. Assign a public IP to the virtual network/subnet that the VM is under

3. Install azure cli & login:

az login

4. Install ssh extension for azure cli

az extension add --name ssh

5. SSH into vm

az ssh vm --private-key-file \path\to\private\key --resource-group <resource group name> --name <vm name> --local-user <local username (default: 'azureuser')>

FAQ

1. How to get vm/resource names

az vm list -d -o table

2. `az login` not working on Windows

az login --use-device-code

How to remove AI summary search feature on Google search

Adele Beitvashahi — Wed, 08 May 2024 21:52:37 +0000

You can't turn it off, use DuckDuckGo or another search engine that's independent of large companies.

How to persist client-side preferences on the client in Svelte (w/o DB)

Adele Beitvashahi — Sun, 21 Apr 2024 08:48:19 +0000

Context

I was in the middle of creating a static site with Svelte. Now of course you might say, why not just make it with plain HTML and CSS. To that I say, it's 2024 and you can go to jail for something like that.

Now, I'm a React developer by trade, but I chose Svelte for this project, because; 1) it ships less JS to the browser due to it not using a virtual DOM. 2) it's excellent for static site generation (SSG), which is what I needed for this project. and most importantly, 3) it was time I finally learned it and saw what the craze was about, I can't go a day without hearing about the amazing developer experience (dx) Svelte provides. And by golly was I in for a treat! Seriously everyone needs to learn Svelte.

Challenge

I needed to provide the website content in different locales, and I wanted to persist their preference across all time and space; all pages, routes, and sessions. This challenge is also applicable to website theming, and potentially any other user preference setting that isn't saved on serverside.

First step is setting and viewing the user preference.

Here's how:

// routes/+page.svelte
<script>
  // defaults to 'en';
  let locale = 'en';
</script>

<h1>Your preference of locale is set to {locale}</h1>
<button on:click={() => locale = "en"}>english</button>
<button on:click={() => locale = "es"}>spanish</button>
<button on:click={() => locale = "fr"}>french</button>

This is all good and well for a page, but if we wanna share it between pages.

Enter, Svelte +layout.svelte. If we move that code to the root layout, every descendant of that route (page.svelte and layout.svelte alike) will have that layout display without changing. If I navigate between routes as long as I don't move up above that layout, the preference will stay.

Now the next issue is accessing that preference from a different component/page. To do that we will need a store. Which is just an object with a subscribe function. Whatever subscribes to that store will update when the store updates.

Here's a brief review of how to create a store in Svelte.

// $lib/utils/stores.js
import { writable } from "svelte/store";
const defaultLocale = 'en';
export const locale = writable(defaultLocale);

The locale selector is located inside the navbar, which I want to be nearly global to this site so it will live in +layout.svelte
Here's how to use that store, in a dumbed down version of my use case.

// routes/+layout.svelte
<script>
  import { locale } from "$lib/utils/stores.js";
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

Now the state of locale will persist across page/route navigations, but it will reset upon refresh and or closing and reopening the site.

So naturally we will want to persist the state somewhere tangible, and more enduring.
How about ✨local storage✨?
Let's do that, we can reuse the code from above and subscribe the localStorage to the store. So updates to store also update localStorage.

// $lib/utils/stores.js
import { browser } from "$app/environment";
import { writable } from "svelte/store";
const defaultLocale = 'en';
// retrieve localStorage value if it's been set already
// important for persisting through refreshes
// broswer check is needed because localstorage doesn't exist on server side
let storedLocale = browser && localStorage.getItem('locale') || defaultLocale;
export const locale = writable(storedLocale);
// subscribe to changes
locale.subscribe((val) => browser && localStorage.setItem('locale', val));

// routes/+layout.svelte
<script>
  import { locale } from "$lib/utils/stores.js";
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

Here's what we've achieved so far:

✅ get & set a preference
✅ persist it through pages/routes
✅ persist through refreshes AND sessions (new tab/window)

But what's this?? there's a new problem. Everytime you reload the page, there's a layout shift, where the value of the preference will be set to its initial default before it fetches the stored localstorage value.

This happens because of server side rendering (SSR), which is an amazing amazing feature that's readily available to us today. It works by partially rendering the website on server side before sending it to the client, and then hydrating it with the rest of the javascript that's necessary for it to fully render, clientside JS basically. I won't go into details of why and how SSR is good, you know how to google.

The problem is that, our user preferences are stored in localstorage, which is only available on client side. The server that's performing SSR is unaware of this localstorage. So when it partially renders the page, localStorage.getItem() just returns undefined. So it will default to the fallback value of "en". Even though the users might have specified otherwise in their previous visit, and stored that preference in their localStorage. There are 2 ways to solve this:

We can add conditional rendering for any affected content on the site so that it doesn't render until our hydration is fully complete, but that will defeat the purpose of SSR.
We can use cookies 🍪 to store user preferences. Because unlike localStorage, cookies persist on user's system and the server will have access to them. Perfect!

P.S. we could also try and fetch localstorage value first thing in our lifecycle events like onMount, but that doesn't follow the Svelte way. It doesn't fully embrace SSR as we are interrupting the initial load with dataloading/fetching, which should be done on server side as much as possible. If we were in React land, then it'd be more acceptable.

To send and receive the preference cookies, we will need to setup a server js file for our layout that will handle the data fetching and initial data setting through Svelte's load function. That data is then loaded into our route, as defined in +layout.svelte.

For this, I'll move most of the store logic to +layout.svelte

// $lib/utils/stores.js
import { writable } from "svelte/store";
export const locale = writable();

// routes/+layout.server.js
import data from "$lib/data/en.json";
export function load({ cookies }) {
  let defaultLocale = 'en';
  data.preferences = { locale: cookies.get("locale") || defaultLocale };
  return data;
}

<script>
// routes/+layout.svelte
  import { locale } from "$lib/utils/stores.js";
  import { browser } from "$app/environment";
  import {setCookie} from "$lib/utils/cookies.js";
  export let data;
  // use the cookie value
  $locale = data.preferences.locale;
  if(browser){
    let storedLocale = localStorage.getItem("locale");
    // prefer localstorage value if cookie is unreliable for any reason.
    $locale = storedLocale || $locale;
  }
  // subscribe localstorage and cookies to the locale store
  $: {
    browser && localStorage.setItem("locale",$locale);
    // setCookie is a custom function I wrote for managing cookies easier, you can find it under this codeblock
    browser && setCookie("locale",$locale);
  }
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

// $lib/utils/cookies.js
import { browser } from "$app/environment";

export function setCookie(name, value, path = "/") {
  if (!browser)
    throw new Error(
      "setCookie can only be used in the browser, make sure to check for browser object first"
    );
  const currentDate = new Date();
  const farFutureDate = new Date(
    currentDate.getTime() + 100 * 365 * 24 * 60 * 60 * 1000
  ); // 100 years from now
  const expires = farFutureDate.toUTCString();
  document.cookie = `${name}=${value}; expires=${expires}; path=${path}`;
}

At this point you might be wondering why do we need localstorage if we are going to use cookies. The answer is redundancy.

And there you have it! This was how to persist data on clientside and avoid layout shifts in SSR.

If you have any comments, questions, or concerns, please keep them to yourself.

All typos are on purpose.

Resources

Cover picture provided by unsplash

DEV Community: Adele Beitvashahi

Deploy your own database as a remote backend service in less than an hour

Context

Challenge

What we're building

The game plan (Agile style)

What you'll need

1. PocketBase, locally

2. Put it behind nginx

3. Put PocketBase in Docker Compose, behind the same nginx

4. Put it on a VPS

DNS first

Prep the server

Get the files there and start it

The server's nginx

Your production superuser

5. A container registry

6. Automate it with GitHub Actions

Finishing touches

P.S. if you only need this for a hobby project, you could skip the pipeline and the registry and stop at step 4. It works fine, you'll just be doing the deploys by hand.

If you have any comments, questions, or concerns, please keep them to yourself.

All typos are on purpose.

Resources

Choosing a video hosting provider for hobby projects

Links

AI Resume Filters Can't Read Between the Lines

How to use Filters in PrimeReact DataTables

How to setup dev containers in windows

How Dev Containers Work in Windows

Correct setup for dev containers in Windows

Connect to Azure VM w/SSH Through Azure CLI

1. Create your VM

2. Assign a public IP to the virtual network/subnet that the VM is under

3. Install azure cli & login:

4. Install ssh extension for azure cli

5. SSH into vm

FAQ

1. How to get vm/resource names

2. az login not working on Windows

How to remove AI summary search feature on Google search

You can't turn it off, use DuckDuckGo or another search engine that's independent of large companies.

How to persist client-side preferences on the client in Svelte (w/o DB)

Context

Challenge

If you have any comments, questions, or concerns, please keep them to yourself.

All typos are on purpose.

Resources

2. `az login` not working on Windows