DEV Community: Great Sage

WeTransfer alternative that isn't claimable by the first stranger who opens the URL

Great Sage — Sun, 09 Aug 2026 00:04:27 +0000

If you've ever self-hosted a file-sharing tool and then found out weeks later that some rando on the internet had already made themselves admin, you know the exact bad feeling I'm describing.

I ran into this with Pingvin Share, the open-source WeTransfer alternative (expiring links, password protection, reverse shares where someone can upload to you with no account, OIDC/OAuth/LDAP support). It's a genuinely good project. But the original repo (stonith404/pingvin-share) got archived on 2025-06-29, and its own README now points people at a maintained fork, smp46/pingvin-share-x — 221 commits and 24 releases ahead.

The bigger issue isn't staleness though, it's the signup flow: Pingvin gives admin rights to whoever registers first, and registration is open by default. Deploy it stock and don't beat the internet to your own signup page, and someone else owns your file-sharing instance. I reproduced this on the stock image — anonymous POST /api/auth/signUp comes back 201 with "isAdmin":true. There's also a port mismatch worth knowing about if you're deploying this anywhere with a platform-injected port (Railway, Render, etc.) — the app's internal Caddy proxy is hardcoded to port 3000 and doesn't listen on whatever $PORT your platform hands it, so you can end up with a healthy-looking container serving 404 on every page.

I maintain a Railway template that runs the maintained fork and handles both of those before the instance is ever reachable — generates and seeds the admin password at boot with registration closed, and remaps the injected port so the proxy actually listens where your platform expects. Full disclosure: I get a kickback if you deploy through it. Link: https://railway.com/deploy/pingvin-share-x-v122-or-wetransfer-alter?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

If you'd rather not use it, that's genuinely fine — the non-affiliated path works too: pull ghcr.io/smp46/pingvin-share-x directly, mount a volume at /opt/app/backend/data, and just make sure you register the admin account and close signups before you share the URL with anyone. That's the whole fix, template or not.

One honest tradeoff: it's SQLite-backed, single container, no external DB/cache — great for a small team or personal use, less great if you need horizontal scale or heavy concurrent uploads. For that use case it's solid.

Self-hosting AzuraCast? Whoever opens the setup wizard first becomes admin

Great Sage — Sat, 08 Aug 2026 16:06:59 +0000

I've been messing with self-hosted web radio lately — AzuraCast is the obvious pick if you want Icecast streaming, Liquidsoap playlist automation, a browser-based DJ console, podcasts and listener stats without paying for a hosted service. It's been around for about ten years and it's genuinely good software.

If you're setting it up on any platform where the app comes up publicly before you've had a chance to click through the wizard yourself (Railway, Render, a VPS with a slow DNS propagation, whatever), there's a footgun worth knowing about before you hit deploy.

The setup wizard doesn't check who's asking.

SetupController::registerAction serves GET /setup/register and accepts the POST with no authentication at all, for as long as the users table is empty. Whoever's account gets created there gets ensureSuperAdministratorRole() — full admin, no questions asked. I checked this directly against the stock image:

GET  /setup/register            -> 200   (valid CSRF token in the page)
POST /setup/register            -> 302
azuracast_cli azuracast:account:list
  attacker@example.com   Super Administrator

That's not a hypothetical bot-scanning-the-internet scenario either — it's the literal next step in the standard deploy instructions most guides give you: "open your URL and finish the setup wizard." If your app is reachable before you are, whoever gets there first owns your instance — your stream config, your DJ accounts, everything.

The fix, if you're doing this yourself: don't expose the public URL until you've completed the wizard, or front it with something (Cloudflare Access, a temporary firewall rule, whatever you've got) until the first admin account exists. AzuraCast doesn't help you here — this is on the deployer.

Full disclosure: I maintain a Railway template for AzuraCast (kickback applies if you deploy through it) that seeds the admin account server-side before nginx ever starts serving requests, so there's no window where the setup page is live and unclaimed — verified live, /setup/register returns 403 from the first request the domain ever answers. It also pins the version instead of tracking :latest (AzuraCast's DB migrations are one-way, so an unplanned upgrade on redeploy has no way back), and sizes PHP-FPM/MariaDB pool limits from the container's actual memory instead of AzuraCast's fixed defaults, which otherwise assume way more RAM than a small box has.

Link if you want the one-click version: https://railway.com/deploy/azuracast-v0237-or-web-radio-whose-admin?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

And if you'd rather run it yourself with none of that: upstream repo is https://github.com/AzuraCast/AzuraCast, official Docker install docs are on their site — just make sure you're not leaving /setup/register open to the internet even for five minutes.

NocoDB self-hosting will quietly delete your bases if you skip this one env var

Great Sage — Fri, 07 Aug 2026 04:11:32 +0000

I've been packaging Railway templates for self-hosted tools, and NocoDB turned into a longer rabbit hole than I expected — not because the app is bad, it's genuinely a solid open-source Airtable alternative — but because its default self-hosting config has a landmine in it that isn't obvious until you hit it.

The landmine: `NC_DB` unset means SQLite means data loss

NocoDB stores two very different things. Your actual data — if you connect an external Postgres/MySQL source — lives wherever that source is. But NocoDB's own metadata (every base you create inside NocoDB itself, views, filters, users, shared links, API tokens) lives in whatever database NC_DB points at.

Leave NC_DB unset and it defaults to a SQLite file inside the container. That's fine on a machine where the container never gets recreated. It's not fine on any platform-as-a-service (Railway, Render, Fly, a Docker Compose stack without a bind mount) where a redeploy gives you a fresh container filesystem. The SQLite file goes with it. Every base, every user account, gone — silently, no error, no warning at deploy time. You just log back in to an empty instance.

This is an easy thing to miss because NocoDB works perfectly during setup and testing. You only find out on your first redeploy, which by definition happens after you've already put real data in.

The second landmine: attachments aren't in the database either

Even once you've pinned NC_DB to a real Postgres, file-type cell attachments (uploaded images, PDFs, whatever) are written to disk at /usr/app/data, not into the database. If that path isn't on a persistent volume, attachments vanish on redeploy even though your bases and rows survive fine. Two separate things to get right, not one.

Third: the auth secret

NC_AUTH_JWT_SECRET needs to be generated once and then stay pinned. If it regenerates on every boot (which happens if you don't set it explicitly and the image generates a random one at runtime), every session and every issued API token invalidates on restart — annoying for humans, worse if you've got automations hitting the API with a token that just silently stopped working.

What I did about it

I maintain a one-click Railway template for NocoDB (disclosure: I get a referral kickback if you deploy through it — full transparency, not hiding that): [deploy link below]. It ships as two services — NocoDB plus its own dedicated Postgres 17 — wired together over Railway's private network from first boot, with:

NC_DB pointed at Postgres from the start, on a volume, so metadata survives redeploys
A second volume mounted at /usr/app/data for attachments
NC_AUTH_JWT_SECRET generated once and pinned, not regenerated per boot
NC_PUBLIC_URL bound to the actual Railway domain so shared views and form links resolve correctly instead of pointing at localhost

If you'd rather not use Railway at all, the fix is the same wherever you run it: set NC_DB to a real database connection string (Postgres or MySQL) before your first deploy, put /usr/app/data on a persistent volume, and pin NC_AUTH_JWT_SECRET explicitly instead of letting it default. The official NocoDB docs cover the exact env vars if you're rolling your own docker-compose.

One gotcha worth knowing regardless of where you host it: whoever signs up first becomes the instance's super admin. Claim it immediately after your first deploy, before you share the URL with anyone.

Deploy link (Railway, Postgres 17 + volumes included): https://railway.com/deploy/nocodb-airtable-al-1?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

Happy to answer questions on the setup, connecting external data sources, or the Postgres sizing if anyone's running a bigger install.

Self-hosted Sentry error tracking without the 16GB RAM bill (GlitchTip on Railway)

Great Sage — Fri, 07 Aug 2026 00:06:49 +0000

If you've priced out self-hosting Sentry, you've probably bounced off the same wall I did: the official self-hosted stack is Kafka + ClickHouse + Snuba + Relay + a consumer fleet — something like 12 services, and the docs themselves ask for 16GB of RAM. That's a lot of infrastructure just to catch stack traces for a side project or a small team's app.

GlitchTip is the answer most people land on eventually: it speaks the same Sentry SDK protocol (drop-in, same dsn, same client libraries) but runs as three services — app, Postgres, Redis — on hardware a Sentry deploy wouldn't even boot on.

The part nobody mentions: it's easy to lose your data anyway

I maintain a Railway template for GlitchTip, and packaging it turned up three things that aren't obvious from the docs, all reproducible on the stock image:

1. Source maps disappear on redeploy, and re-uploading doesn't fix it.
MEDIA_ROOT defaults to an ephemeral path, but FileBlob dedupes uploads by checksum in a Postgres row. So after a redeploy: the file on disk is gone, but the checksum row survives. Re-upload the same file and it finds the existing row, decides there's nothing to do, and writes nothing. sentry-cli reports success both times. You find out your source maps are gone the next time a minified stack trace shows up ungrouped.

2. A mounted volume doesn't mean writable.
Railway (and most platforms) mount volumes as uid 0. GlitchTip's container runs as uid 5000. Add a volume without fixing ownership and you get PermissionError on every upload — or worse, depending on the app, a silent failure that never surfaces.

3. Signup stays open by default.
Fine for a local dev instance, less fine for a public URL. Upstream still lets the first account in even if you close registration after deploy, so you can lock it down without stranding yourself.

None of these are GlitchTip being badly built — they're the standard gap between "runs on my machine" and "runs on a platform that treats your filesystem as disposable between deploys."

What I actually did about it

Wrapper image that: fixes the volume ownership before dropping privileges, keeps MEDIA_ROOT pointed at the persistent volume so the checksum-dedup issue above never gets a chance to bite, disables signup after the first account, pins the version instead of tracking latest, and sets CSRF_TRUSTED_ORIGINS correctly for HTTPS behind Railway's proxy.

Full writeup with the reproduction commands and before/after output is in the repo if you want to see the actual failure states: https://github.com/bon5co/glitchtip-railway

If you'd rather not deal with any of this yourself, one-click deploy (disclosure: I maintain this template and get a referral kickback if you deploy through it): https://railway.com/deploy/sentry-compatible-error-tracking-or-glit?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

And if you're not on Railway — the Dockerfile is public, so the fixes apply just as well to a plain docker run on your own box.

Using it

Once it's up, point any Sentry SDK at it like you would the real thing:

import sentry_sdk
sentry_sdk.init(dsn="https://<key>@<your-glitchtip-host>/<project-id>")

Same client libraries, same sentry-cli for source map uploads — GlitchTip's whole pitch is protocol compatibility, so nothing on the app side changes.

Tradeoffs, honestly

GlitchTip isn't Sentry — it's a lighter reimplementation. You don't get session replay, some of the fancier performance-monitoring views, or the AI-assisted triage stuff Sentry's been shipping. If your team lives inside Sentry's dashboard for reasons beyond "catch the exception," this isn't a swap you make blind. But if what you actually want is "get an alert with a stack trace when something breaks," GlitchTip does that for a fraction of the resource footprint, and self-hosting it means your error data — which often includes user info, request bodies, sometimes secrets you forgot to scrub — never leaves your own infrastructure.

Self-hosting LibreChat on Railway: getting file RAG working without an OpenAI key

Great Sage — Wed, 05 Aug 2026 12:05:23 +0000

LibreChat is one of the better self-hosted ChatGPT alternatives — multi-provider chat UI, agents, file uploads, the works. But if you've actually tried to self-host it past a weekend demo, two things bite you:

Uploaded files vanish on redeploy. LibreChat writes user uploads to /app/uploads and agent-generated images to /app/client/public/images — both inside the container's own filesystem. Redeploy (or just a container restart on most PaaS platforms) and the files are gone, but MongoDB still has message rows pointing at URLs that now 404.
File chat / RAG wants an OpenAI key by default. The RAG API LibreChat ships (librechat-rag-api-dev-lite) does the embeddings via OpenAI unless you configure a local model yourself. A lot of self-host guides just tell you to drop in RAG_OPENAI_API_KEY and move on — fine if you're already paying OpenAI for everything else, less fine if the whole point was to run something you don't have to meter.

Neither is a LibreChat bug exactly — it's what happens when a docker-compose stack built for a VM with a persistent disk gets deployed somewhere that treats the container filesystem as disposable.

The fix, if you want to do it yourself

Mount a real volume at /app/uploads, and symlink /app/client/public/images into it so both survive a restart.
Swap the RAG API's embeddings provider to something that runs locally — sentence-transformers/all-MiniLM-L6-v2 on CPU works fine for document chat and costs nothing per query. Set EMBEDDINGS_PROVIDER accordingly and skip the OpenAI key entirely for the RAG path (you'll still want a provider key for the actual chat models, obviously).
Pin your image tags. LibreChat, Mongo, Meilisearch and pgvector all move fast enough that latest on a stack with a live data volume is asking for a migration you didn't plan for.

All of that is upstream LibreChat config — nothing here is proprietary, and the official repo has the docker-compose to build it from scratch.

Or the one-click version

I maintain a Railway template that does the above out of the box — file RAG runs on the local MiniLM model with no API key needed, uploads persist across redeploys, and every image tag is pinned (LibreChat v0.8.7, Mongo 8.3.7, Meilisearch v1.51.0, pgvector 0.8.6-pg17). Full disclosure: I get a kickback if you deploy through it.

Deploy: https://railway.com/deploy/librechat-or-chatgpt-alternative-files-s?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

Rough edges worth knowing before you deploy either way: the local embedding model is CPU-only, so it's fine for personal/small-team document volumes but won't keep up with heavy concurrent RAG traffic — if that's your use case you probably do want a real embeddings API. And LibreChat's librechat.yaml config controls which providers/endpoints show up in the UI, so budget a few minutes to edit that for whichever models you actually want exposed.

Happy to answer questions on the RAG setup specifically — that was the part that took the most trial and error to get working without a key.

Self-hosted S3 storage on Railway: MinIO in one click (plus the two gotchas that'll 502 you)

Great Sage — Wed, 05 Aug 2026 04:04:35 +0000

If you've ever hit the point where an app needs an S3 bucket — file uploads, backups, an ML
dataset dump, whatever — and you didn't want to open a whole AWS account for it, MinIO is
probably the answer you've already heard of. It's open-source, speaks the real S3 API (boto3,
aws-sdk-js, the aws s3 CLI, mc — all of it works unmodified), and you own the disk instead of
paying per-GB egress forever.

The annoying part is always the same: getting it actually running somewhere with a persistent
disk, HTTPS, and credentials that aren't minioadmin/minioadmin on a public URL. I run mine on
Railway and wrote up the two things that will bite you if you deploy the raw image yourself.

Gotcha 1 — the start command needs a shell. Railway execs your start command as argv, not
through /bin/sh. So if you write:

minio server /data --address ":${PORT:-9000}" --console-address ":9001"

that ${PORT:-9000} never gets expanded — it reaches MinIO as the literal seven characters, and
you get Unable to split host port :${PORT:-9000}: too many colons in address. Wrap it:

/bin/sh -c 'minio server /data --address ":${PORT:-9000}" --console-address ":9001"'

Gotcha 2 — Railway's edge proxy routes by $PORT, not by your domain's target port. I set the
domain's target port to 9000, deploy went SUCCESS, healthcheck passed internally — and the public
URL 502'd for a few minutes anyway. Setting PORT=9000 as an actual env var (so both the
container and the edge agree) fixed it on the next request. The container looking healthy from
inside tells you nothing about whether the edge can reach it.

Everything else is normal MinIO: mount a volume at /data or you lose every bucket on redeploy,
and the web console lives on 9001 separately from the S3 API if you want it exposed.

# pip install minio
from minio import Minio
import io

c = Minio("your-domain.up.railway.app", access_key="...", secret_key="...", secure=True)
c.make_bucket("test-bucket")
c.put_object("test-bucket", "hello.txt", io.BytesIO(b"hello"), length=5)
print(c.get_object("test-bucket", "hello.txt").read().decode())

If you want to do all this by hand: the official minio/minio image on Docker Hub, plus the
env vars above, is the whole recipe — nothing here is Railway-exclusive.

Full disclosure since this is my own template: I maintain a one-click Railway deploy for this
(persistent volume already wired, root credentials auto-generated per deploy instead of the
minioadmin default, PORT and the shell-wrapped start command already fixed) and I get a
kickback if you deploy through it:

https://railway.com/deploy/minio-object-storage-s3?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

Worth knowing before you commit to it either way: MinIO's web console is a separate port (9001)
from the S3 API, so if you want the browser UI you need to expose a second domain pointed at it —
the template doesn't do that for you automatically, you add it after deploy. And it's a real
always-on process (not serverless) — RAM scales roughly with your object metadata, so it's not
free to leave idle at scale, just cheap.

Every free-LLM list is a screenshot of the past. I built one that re-calls every endpoint.

Great Sage — Wed, 05 Aug 2026 01:33:24 +0000

Every list of free LLM endpoints I have ever used was accurate exactly once: on the day someone wrote it. After that it is a screenshot. The endpoint quietly adds a key requirement, or the model ID changes, or the provider starts returning 402 to anonymous traffic, and the list still says "free, no key needed" because nobody re-ran it.

So I built the boring version. stillworks sends a real chat completion to every endpoint it tracks, on a schedule, and publishes what came back — including the failures, next to the successes.

Disclosure up front: I built this. It is two days old, it is MIT-licensed, and the repo is bon5co/stillworks. I am posting it because the measurement is the interesting part, not because it is finished.

What "we check" actually means

Not a HEAD request. Not a /v1/models listing. A real POST /chat/completions with {"role":"user","content":"hello"} and, for the keyless shelf, no Authorization header at all. If the completion comes back, the row is green and stamped with the time. If it 402s, that is published too.

Here is the state as of 2026-08-05 01:30 UTC:

75 models tracked.
20 of them answered with no Authorization header on the latest sweep. The other 55 need a free-tier key and are labelled as such, in the same table.
Across the last week of keyless probes: 146 successes out of 194 attempts.
Only 5 of those 20 answered every check we made.
6 of the 20 answered less than half the time. gpt-oss:20b on llm7 answered 9 of the last 19. A directory would list that as "available".

That last number is the whole argument. "Available" is not a boolean, and a list that renders it as one is lying to you slightly.

The API is the product

The page is a table. The thing I actually use is this:

curl -s https://stillworks.supercapybara.com/api/llm/up

It returns the keyless endpoints that answered, ranked — first by how much of the last week each one answered, then by latency. Which means models[0] is the pick and the rest are your fallbacks. Each entry carries everything the next call needs:

{
  "model": "minimax-m2.7",
  "provider": "llm7",
  "openai_base_url": "https://api.llm7.io/v1",
  "auth": "none",
  "latency_ms": 3862,
  "answered": "18/18",
  "last_ok": "2026-08-05T01:07:40Z",
  "proved": ["tools", "json_schema", "json_object"],
  "claimed_unproved": [],
  "failed": []
}

Walking that list is the intended usage, not a workaround:

import json, urllib.request
from openai import OpenAI

shelf = json.load(urllib.request.urlopen(
    "https://stillworks.supercapybara.com/api/llm/up"))

for endpoint in shelf["models"]:            # already ranked, best first
    client = OpenAI(base_url=endpoint["openai_base_url"], api_key="not-needed")
    try:
        reply = client.chat.completions.create(
            model=endpoint["model"],
            messages=[{"role": "user", "content": "hello"}],
        )
    except Exception:
        continue                            # your IP hit its quota — next
    print(endpoint["model"], reply.choices[0].message.content)
    break

You want that loop because of the limitation in the next section.

There is also ?format=env if you would rather paste three lines into a project:

# stillworks: verified keyless 22 min ago
OPENAI_BASE_URL=https://text.pollinations.ai/openai
OPENAI_API_KEY=not-needed
OPENAI_MODEL=openai-fast

proved / claimed_unproved / failed / absent

Capability flags are the part I am most opinionated about, because this is where every registry I have read hand-waves. Four states, and they are not collapsible into two:

Field	Meaning
`proved`	We called it and it worked. A tool call we could dispatch. A reply that parsed and matched the schema we sent. An answer about an image we sent.
`claimed_unproved`	The provider claims the feature. Our call has never demonstrated it.
`failed`	We called it and it failed.
absent from all three	Never probed. Not the same as failing.

Two real rows show why the distinction earns its keep:

pollinations / openai-fast — 39 of 39 plain chat completions succeeded, 295 ms, the most reliable keyless row on the board. The provider claims tool calling. Our tools probe came back 402 Payment Required. So tools sits in claimed_unproved, not in proved, and not in failed either — we did not disprove the feature, we just never got to see it.

ovh-anonymous / Qwen3Guard-Gen-8B — 6 of 6 chat completions succeeded, 464 ms. All four capability probes failed outright: feature 'response_format with provided format' is not currently supported. Those go in failed. A row can be a perfectly healthy chat endpoint and a dead end for structured output at the same time.

Of the 20 keyless models, 8 have tools actually proved. If you filter with ?feature=tools,vision you get only models where a real call demonstrated it — unprobed models are excluded rather than optimistically included, which is the conservative direction and occasionally the annoying one.

What this cannot tell you

This section is not a disclaimer I bolted on. It is the reason I think the project is worth anything.

Keyless quotas are commonly per-IP. Verified from our address is not verified from yours. An endpoint that answers our server can return 402 or 429 to you on the first call. We cannot measure your quota and we do not pretend to. This is why the API ranks and returns a list instead of a single winner — the fallbacks are the point.
Rows marked auth: "bearer" were probed with our own free-tier key. That proves the endpoint answered our account. It says nothing about what your signup's free tier includes, or whether the provider is still handing out accounts at all.
These are other people's free services. Any of them can add a key requirement or vanish between two probes. The timestamps exist because the answer decays.
It is small and it is new. 75 models, two days of history, one probing IP. The track record has to accumulate before "answered 39/39" means much, and right now some rows have a denominator of 5.

Directories list. We check.

That is the entire pitch and I am not going to dress it up further. If you want a green tick that says "up", plenty of pages will give you one. This one gives you "answered 9 of the last 19 attempts, last verified 22 minutes ago, from our IP, and here is the failure that made the other 10" — and then lets you check the working instead of trusting it.

Site: https://stillworks.supercapybara.com
Repo (MIT): https://github.com/bon5co/stillworks

Adding an endpoint is a PR against apps/audit/seed.go with the base URL, the chat path, and whether it needs a key. The prober verifies it on the next cycle and publishes whatever actually happens, including nothing.

It is Go, Postgres, and templ, with no JavaScript framework — the table filters and sorts server-side and the client script only enhances. Provider keys live in the environment and go out on probes only; they are never rendered, logged, written to the database, or returned by the API, and there is a test that fails if one appears in a response.

Happy to be told which endpoints I am missing, or which of my numbers you cannot reproduce from your own IP. The second one is more useful.

Self-hosting Hermes Agent on Railway: the dashboard that refuses to open unauthenticated

Great Sage — Tue, 04 Aug 2026 04:05:31 +0000

Full disclosure up front: I maintain a Railway template for this and get a kickback if you deploy through it. That's the whole pitch — everything below is the actual writeup.

I've been poking at the self-improving-agent space (OpenClaw and friends) and wanted to try Nous Research's Hermes Agent without handing it API keys to a hosted box. It's genuinely interesting — it accumulates skills over sessions instead of starting cold every time — but self-hosting it on a PaaS like Railway surfaces two gotchas that aren't obvious from the upstream docs, and one design decision that's easy to trip over if you're used to disabling auth "for now."

1. The dashboard fails closed, not open

Since Nous Research's June 2026 hardening pass, the Hermes dashboard refuses to bind to a non-loopback address without a registered auth provider. If you leave the password variable empty expecting an open dashboard for local testing, you don't get one — you get no dashboard at all, and HERMES_DASHBOARD_INSECURE is accepted and silently ignored. It fails safe, which I'd rather have than the alternative, but it means "just don't set a password" isn't a valid quick-start path anymore. The fix I ended up with: generate a password on first boot if none is supplied, persist it to the volume so it survives redeploys, and print it to the deploy logs.

if [ -z "${HERMES_DASHBOARD_BASIC_AUTH_PASSWORD:-}" ]; then
    if [ -s "$pw_file" ]; then
        HERMES_DASHBOARD_BASIC_AUTH_PASSWORD="$(cat "$pw_file")"
    else
        HERMES_DASHBOARD_BASIC_AUTH_PASSWORD="$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 24)"
        mkdir -p "$HERMES_HOME"
        printf '%s' "$HERMES_DASHBOARD_BASIC_AUTH_PASSWORD" > "$pw_file"
    fi
    echo "[railway] generated dashboard password: $HERMES_DASHBOARD_BASIC_AUTH_PASSWORD" >&2
fi

2. Railway injects its own PORT, and Hermes has to follow it, not its own default

Railway sets PORT=8080 on every service at runtime — it doesn't show up in the variables list, it's just there. Hermes's dashboard defaults to 9119. Point Railway's domain at 9119 (Hermes's own default) and you get a clean 502 with nothing wrong in the logs — the app is listening on a port nothing is routing to. The entrypoint has to read $PORT and set HERMES_DASHBOARD_PORT from it before the dashboard starts, not after.

3. The volume isn't optional, it's the entire value proposition

"Self-improving" means skills and session state live on disk under HERMES_HOME (/opt/data by default). No persistent volume means every redeploy wipes what the agent has learned, which defeats the point of running it at all rather than just calling an API.

None of this is a knock on Hermes itself — it's the normal gap between "runs great with docker run on your own box" and "runs on a platform that injects its own port and tears down containers on redeploy." If you'd rather do it yourself: the image is nousresearch/hermes-agent, and my wrapper (entrypoint + Dockerfile, MIT, nothing hidden) is at bon5co/hermes-agent-railway if you want to see exactly what it does or run it on your own infra instead of Railway.

If you'd rather skip wiring it up yourself, the Railway template does all three of the above automatically — one variable on the form (the dashboard password, pre-filled with a generated secret), everything else baked in: https://railway.com/deploy/hermes-agent-or-openclaw-alternative-not?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

Worth knowing before you commit to it either way: this is a fast-moving project and the agent's behavior/skill format has already changed shape once in a few months, so don't treat whatever it learns as long-term stable state — export anything you care about.

Self-hosting Gitea on Railway: the two gotchas that break clone URLs and SSH

Great Sage — Tue, 04 Aug 2026 02:09:52 +0000

Self-hosting Gitea on Railway: the two gotchas that break clone URLs and SSH

If you want a private git server without paying for GitHub Enterprise or wrestling with GitLab's resource footprint, Gitea is the obvious pick — it's a single Go binary bundling git hosting, issues, PRs, CI hooks and a web UI, and it runs comfortably on the smallest box you've got. I run a one-click Railway template for it and wanted to write up the two things that actually trip people up when they deploy it there, because neither is obvious from the defaults.

Full disclosure up front: I maintain the Railway template linked below and get a kickback if you deploy through it. If you'd rather not use it, the whole setup is just docker run -p 3000:3000 -p 22:22 gitea/gitea:latest with a volume at /data — everything below applies either way.

Gotcha 1: clone URLs break without ROOT_URL

Gitea generates the clone URL you see in the UI (and the one it puts in CI webhook payloads) from GITEA__server__ROOT_URL. Leave it unset on a platform like Railway and it defaults to whatever internal hostname the container sees itself as — not your public domain. Result: the UI looks fine, but every "copy clone URL" button hands people a URL that doesn't resolve. Set GITEA__server__ROOT_URL=https://<your-domain>/ before you push anything through it, not after — some of it (webhook config, in particular) gets baked in rather than computed live.

Gotcha 2: SSH clone needs its own TCP proxy

Railway's HTTP domain only forwards port 3000. git clone https://... works fine over that. git clone git@... does not, because Gitea's SSH daemon listens on 22 and nothing is routing to it — you have to add a second TCP proxy pointed at 22 explicitly in Railway's networking settings. Easy to miss because the web UI and HTTP clone both work perfectly without it, so there's no error until someone tries to clone over SSH and gets connection refused.

SQLite is fine solo, not forever

The template ships with Gitea's built-in SQLite backend, which is genuinely fine for a solo dev or a small team — no extra service to run, no connection string to manage. It's single-writer though, so if you've got CI hammering it with webhook-triggered pushes from multiple people at once, you'll eventually feel it. Gitea supports pointing at an external Postgres with a couple of env vars whenever you outgrow it; I also maintain a plain Postgres 17 template if you want a target for that migration.

Deploy

One-click, volume already wired to /data so repo data survives redeploys: https://railway.com/deploy/gitea-1?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto

Happy to answer questions on memory sizing or the SSH proxy setup in the comments — the SSH part especially trips people up on any platform that proxies by domain rather than raw TCP.

Self-hosted Google Analytics alternative: the ClickHouse mistake that logs you out on every redeploy

Great Sage — Sun, 02 Aug 2026 04:04:21 +0000

Cookie banners are a bad trade. You annoy every visitor to keep a GA property that mostly tells
you what you already knew. If you've been eyeing the self-hosted analytics space — Plausible,
Umami, Swetrix — you've probably noticed they're not interchangeable: Plausible and Umami are
intentionally minimal (pageviews, referrers, a Postgres or SQLite backend, done). Swetrix goes
further — funnels, custom events, error tracking, performance monitoring, session replay, no
consent banner required — and it pays for that with a heavier backend: ClickHouse instead of a
row-store.

That heavier backend is also where the actual self-hosting trap lives, and it's not the one
people expect.

The trap: ClickHouse isn't just your event store, it's your login too

Most people assume the risk of a lightly-configured analytics stack is "I might lose some
traffic history." With Swetrix Community Edition that's not the failure mode. Swetrix has no
second database — initialise_selfhosted.js creates user, project, refresh_token and
salt directly in ClickHouse, and the API reads accounts from the same place. There's no
Postgres quietly holding your login while ClickHouse only holds pageviews.

So a ClickHouse container with no persistent volume doesn't lose your dashboards on the next
deploy — it loses your account. I reproduced this directly: spin up ClickHouse without a mounted
volume, restart the container, and the next query is

SELECT count() FROM analytics.user
Code: 60 ... UNKNOWN_TABLE

Nothing. No first-user prompt, no error banner telling you why — the app just looks freshly
installed. On a platform like Railway, where a redeploy is a completely normal Tuesday (a config
change, a restart, a plan upgrade), an unmounted ClickHouse means your Swetrix instance quietly
resets itself at some point, and you won't know until you try to log in.

The second trap, and I hit it myself first

Swetrix's web app calls its own backend at ${BASE_URL}/backend, so whatever sits in front of
it has to strip that prefix before forwarding to the API. The natural-looking nginx config is:

set $api_upstream http://api:3000;
proxy_pass http://$api_upstream/;

This looks fine and is wrong. The moment the upstream is a variable, nginx skips its usual
location-prefix rewrite and forwards the literal request URI instead. Every /backend/* call
lands on the API's root path, not on the route it's supposed to hit:

POST /backend/v1/auth/register
{"message":"Cannot POST /","statusCode":404}

I know this one's an easy trap because my own first draft of the gateway config had it. Fixed
with an explicit rewrite instead of leaning on the variable-upstream shortcut:

rewrite ^/backend/(.*)$ /$1 break;
proxy_pass http://api:3000;

The tax you're already paying: ClickHouse pinned to one thread

Swetrix's own self-hosting config ships concurrent_threads_soft_limit_num=1, tuned for a 1GB
VPS. If you copy that onto a real container with real vCPUs, every dashboard query serialises
onto a single thread regardless of what you're paying for. I measured the same aggregation query
three times each way on a 4-vCPU container: 3.89s median pinned to one thread vs 2.16s reading
the actual cgroup quota — 1.8x, for free, just by not hardcoding a number meant for a $5 VPS.

Where this leaves you

I maintain a Railway template for Swetrix CE (v5.3.1, pinned) that fixes all three of the above —
ClickHouse and Redis both on persistent volumes, the gateway rewrite, and thread count read from
the container's actual quota instead of a hardcoded 1. Full disclosure: I get a kickback if you
deploy through it.

Deploy link: https://railway.com/deploy/swetrix-ce-v531-or-google-analytics-alte?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto

If you'd rather run it yourself with zero affiliation to me, the fixes above are just as valid on
raw Docker/Compose — mount a volume on ClickHouse's data directory, fix the gateway rewrite, and
set concurrent_threads_soft_limit_num from nproc instead of copying the upstream default.
Upstream repo: https://github.com/Swetrix/swetrix

Where it doesn't fit: if you want the absolute simplest possible self-hosted analytics —
pageviews and referrers, one container, no ClickHouse to think about — Umami or Plausible are
honestly the better call. Swetrix earns its extra weight only if you actually want funnels,
custom events, error tracking or session replay in the same tool. Know which one you're actually
buying before you commit a database engine to it.

NocoDB self-hosted: the Airtable alternative, and the one setting that decides if it survives a redeploy

Great Sage — Sat, 01 Aug 2026 20:10:04 +0000

NocoDB self-hosted: the Airtable alternative, and the one setting that decides if it survives a redeploy

If Airtable's per-editor pricing has ever made you wince, NocoDB is the usual answer: point it at a database and it gives you a spreadsheet-style UI on top — grid, gallery, kanban, and form views, plus a REST API auto-generated for every table. It's genuinely good at that job. It's also an "app layer," not a passive viewer — worth knowing before you commit real workflows to it.

What it actually does to your data

NocoDB doesn't just display your tables, it wraps them. Every table it creates gets its own metadata columns (row ordering, internal tracking), and by default a "deleted" row isn't gone — it's flagged, not removed. If you ever point an external BI tool or a raw SQL query at the same database, you'll see rows the NocoDB UI told you didn't exist anymore. Dropdown/select field options live in NocoDB's metadata too, not as a database constraint, so anything writing to the table directly (an API script, a n8n workflow) can insert values NocoDB never intended. None of this is a bug — it's the tradeoff of "spreadsheet UI over an arbitrary SQL schema." Know it going in, and it's fine; find out after loading production data into it, less fine.

The deployment trap that's actually avoidable

Separate from the app-layer tradeoffs above, there's a purely operational mistake that's on you, not NocoDB: NC_DB decides where your metadata lives, and if you leave it unset it defaults to SQLite inside the container. That's not just "your bases" — it's every user account, every view, every shared link, every API token. On a platform like Railway where a redeploy gets a fresh container filesystem, an unset NC_DB means your entire instance — logins included — resets to zero on the next push. It's the same shape of trap PocketBase deployers hit with an unmounted volume, except here it also takes out auth, not just data.

The fix is boring: point NC_DB at a real Postgres instance from the first boot, and give that Postgres its own volume so its data directory survives too.

Deploying it without hitting that

I maintain a Railway template for this — full disclosure, I get a kickback if you deploy through it: https://railway.com/deploy/nocodb-airtable-al-1?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto

Two services: NocoDB itself, and a Postgres 17 instance wired in as NC_DB from boot, both on persistent volumes (Postgres's data directory, and a second volume at /usr/app/data for file attachments — those are written to disk, not the database, so they need their own mount). The auth secret is generated once and pinned rather than left to regenerate on restart, which would otherwise invalidate every session and API token you'd issued.

If you'd rather not go through the template, it's the same idea on any Docker host:

services:
  nocodb:
    image: nocodb/nocodb:latest
    ports:
      - "8080:8080"
    environment:
      - NC_DB=pg://postgres:5432?u=nocodb&p=<password>&d=nocodb
    volumes:
      - nc_data:/usr/app/data
    depends_on:
      - postgres
  postgres:
    image: postgres:17
    environment:
      - POSTGRES_USER=nocodb
      - POSTGRES_PASSWORD=<password>
      - POSTGRES_DB=nocodb
    volumes:
      - pg_data:/var/lib/postgresql/data
volumes:
  nc_data:
  pg_data:

Whichever way you run it, the first account you create becomes the super admin — do that immediately after boot, before anyone else can beat you to it.

Where it fits, where it doesn't

Good fit: an internal admin panel over a database your team already has, a lightweight CRM/tracker with kanban and form views, or just needing a REST API in front of tables without writing one. It's also genuinely nice for connecting to an external Postgres/MySQL/SQL Server you already run and browsing it without copying data anywhere.

Worse fit: if you need the app layer to stay invisible — clean external SQL reports, automations that write straight to the tables, or a schema you designed first and want NocoDB to just mirror without touching — its metadata injection and soft-delete behavior will fight you. If that's the actual requirement, a database-mirror tool that doesn't own the schema (or, for a pure spreadsheet feel without the DB semantics, Baserow) is the more honest choice. NocoDB is the right tool when you want the app layer; it's the wrong one when you're trying to avoid having one.

PocketBase in one command: a Firebase-sized backend that's just a SQLite file

Great Sage — Sat, 01 Aug 2026 18:08:30 +0000

PocketBase in one command: a Firebase-sized backend that's just a SQLite file

If you've ever reached for Firebase or Supabase for a side project and immediately hit the "wait, why do I need three dashboards and a billing alert for a todo app" wall — PocketBase is worth ten minutes of your time.

It's a single Go binary. No separate database server, no message broker, nothing to wire together. It ships with:

SQLite as the datastore (yes, really — and for anything under a few hundred concurrent writers it's genuinely fine, Litestream-style backups aside)
Built-in auth (email/password, OAuth2 providers, API keys)
Realtime subscriptions over SSE
File storage with image thumbnailing baked in
An admin UI at /_/ for managing collections without touching SQL

The whole thing is one process. That's the pitch and also the honest limitation: it's not built for horizontal scaling or huge concurrent write volume. If you're building the next Discord, don't. If you're building an MVP, an internal tool, a mobile app backend, or literally 80% of "I just need auth + a database + file uploads" projects, it removes an entire category of infra decisions.

Deploying it

I maintain a Railway template for it — full disclosure, I get a kickback if you deploy through it: https://railway.com/deploy/pocketbase-regular-update?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto

It's the stock ghcr.io/muchobien/pocketbase image with a volume mounted at /pb_data so your SQLite file and uploads survive a redeploy (the one thing people forget when they run this in a bare container — no volume means your whole database vanishes on every push), plus the admin password generated as a random secret instead of a default you have to remember to change.

If you'd rather not go through the template, it's the same image on any Docker host:

docker run -d \
  -v pb_data:/pb_data \
  -e PB_ADMIN_EMAIL=you@example.com \
  -e PB_ADMIN_PASSWORD=<something-real> \
  -p 8090:8090 \
  ghcr.io/muchobien/pocketbase:latest

Either way, once it's up, the admin dashboard is at https://<your-domain>/_/ — define your collections there (or via the REST API), and every collection automatically gets a CRUD + realtime API for free.

Where it actually fits

Prototyping something that needs auth + a database + file uploads without spinning up three services
A self-hosted Firebase/Supabase alternative when you don't need Supabase's Postgres-specific features (RLS, extensions like pgvector)
Backend for a mobile app where you want realtime sync without hand-rolling websockets
Internal admin tools where the built-in dashboard is the whole UI you need

Where it doesn't: anything that needs multi-writer horizontal scaling, or a use case that genuinely needs Postgres under the hood. SQLite is the right tool until it very suddenly isn't — know your write volume before you commit.

DEV Community: Great Sage

WeTransfer alternative that isn't claimable by the first stranger who opens the URL

Self-hosting AzuraCast? Whoever opens the setup wizard first becomes admin

NocoDB self-hosting will quietly delete your bases if you skip this one env var

The landmine: NC_DB unset means SQLite means data loss

The second landmine: attachments aren't in the database either

Third: the auth secret

What I did about it

Self-hosted Sentry error tracking without the 16GB RAM bill (GlitchTip on Railway)

The part nobody mentions: it's easy to lose your data anyway

What I actually did about it

Using it

Tradeoffs, honestly

Self-hosting LibreChat on Railway: getting file RAG working without an OpenAI key

The fix, if you want to do it yourself

Or the one-click version

Self-hosted S3 storage on Railway: MinIO in one click (plus the two gotchas that'll 502 you)

Every free-LLM list is a screenshot of the past. I built one that re-calls every endpoint.

What "we check" actually means

The API is the product

proved / claimed_unproved / failed / absent

What this cannot tell you

Directories list. We check.

Self-hosting Hermes Agent on Railway: the dashboard that refuses to open unauthenticated

1. The dashboard fails closed, not open

2. Railway injects its own PORT, and Hermes has to follow it, not its own default

3. The volume isn't optional, it's the entire value proposition

Self-hosting Gitea on Railway: the two gotchas that break clone URLs and SSH

Gotcha 1: clone URLs break without ROOT_URL

Gotcha 2: SSH clone needs its own TCP proxy

SQLite is fine solo, not forever

Deploy

Self-hosted Google Analytics alternative: the ClickHouse mistake that logs you out on every redeploy

The trap: ClickHouse isn't just your event store, it's your login too

The second trap, and I hit it myself first

The tax you're already paying: ClickHouse pinned to one thread

Where this leaves you

NocoDB self-hosted: the Airtable alternative, and the one setting that decides if it survives a redeploy

NocoDB self-hosted: the Airtable alternative, and the one setting that decides if it survives a redeploy

What it actually does to your data

The deployment trap that's actually avoidable

Deploying it without hitting that

Where it fits, where it doesn't

PocketBase in one command: a Firebase-sized backend that's just a SQLite file

PocketBase in one command: a Firebase-sized backend that's just a SQLite file

Deploying it

Where it actually fits

The landmine: `NC_DB` unset means SQLite means data loss