DEV Community: Harry Agustiana

I Almost Shipped a Broken Database on Tencent EdgeOne Makers. Here's What Fixed It

Harry Agustiana — Sat, 29 Aug 2026 06:25:27 +0000

Here's a mistake I bet a lot of developers coming from traditional hosting will make on their first serverless edge project: assuming a local database file will just... work.

I made that mistake building OptiQ, a sales-tracking app for small optical shops, on Tencent EdgeOne Makers. This post is less "here's a polished tutorial" and more "here's the debugging path I took," because I think the reasoning matters more than the final answer.

The Project, Briefly

Small optical shops have a messy sales pattern that most POS templates don't handle well. A customer might buy:

Just a frame
Just a lens
A complete pair (frame + lens)
Softlens
Small accessories (cleaning solution, frame screws) — no prescription needed On top of that, the shop needs to track refraction data (OD/OS, cylinder, axis) per customer, and sometimes link it to a sale — but not always. OptiQ is my answer to that: a small, relational, low-cost app built specifically around that flexibility.

Low-cost was non-negotiable here. I'm the only IT person at my company, so I don't get to justify infrastructure spend for a side project — it has to run on free tiers, or it doesn't ship.

Mistake #1: Treating an Edge Function Like a Regular Server

For context, EdgeOne Makers is the rebrand of EdgeOne Pages (as of June 2026) — it grew from "frontend hosting" into a full-stack platform for Web and AI Agent apps, with support for React, Vue, Next.js, Astro, and a few agent frameworks. That expanded scope is what made it worth using for something beyond a static site.

My plan was simple: static frontend on Pages, API logic on Pages Functions, SQLite file for storage. Deploy was smooth — genuinely, push-to-live in minutes, no CDN or SSL setup needed.

Then I hit the wall: edge functions are stateless. There's no persistent filesystem, and a given request might get routed to a different edge instance than the last one. A .db file written on one request could be gone — or inconsistent — by the next. This isn't an EdgeOne-specific limitation; it's true of serverless edge compute generally. But it's an easy thing to forget if your mental model still comes from VPS-style deployments.

Lesson: figure out your state strategy before you write a single API route, not after your first weird bug report.

Mistake #2 (Almost): Picking a Database That Sleeps When You Need It Awake

Once I accepted I needed a managed database, I evaluated three options:

Option 1 — EdgeOne's native KV store. Fast, simple, and built in. But it's key-value only — no joins, no relational queries. For OptiQ, that would mean hand-rolling indexes for every access pattern (transactions by customer, transactions by date range) and computing monthly totals by pulling records into app code and summing manually. It works, but it's the kind of thing that quietly turns into technical debt.

Option 2 — Supabase. Full Postgres, generous free tier, great DX. Then I read the fine print: free projects pause after ~7 days of inactivity and need a manual restore to wake back up. A shop that doesn't sell something every single day could open the app to a database that's asleep. That's a bad failure mode for a business tool, even a small one.

Option 3 — Turso. SQLite (libSQL), but run as a managed service and queried over HTTP — which means it works fine from a stateless edge function, unlike a local file. Real SQL (joins, constraints, aggregates), no idle-pause behavior. This is what I went with, and the schema I'd already sketched needed almost zero changes to work with it.

The Part of the Schema That Actually Matters

Most of OptiQ's schema is unremarkable — customers, products, transactions, transaction line items. The one decision worth calling out:

CREATE TABLE transactions (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  customer_id INTEGER REFERENCES customers(id),
  refraction_id INTEGER REFERENCES refractions(id), -- nullable, on purpose
  total REAL NOT NULL
);

refraction_id is nullable. That's the whole trick. Without it, I'd have needed separate transaction tables (or awkward sentinel values) for "sale with a prescription attached" vs "sale without one" — like buying a bottle of lens cleaner shouldn't require a fake prescription record just to satisfy a NOT NULL constraint. One nullable foreign key instead of a schema fork.

Where EdgeOne Makers' Full-Stack Positioning Actually Paid Off

The thing I didn't expect going in: not having to stitch together three separate vendors. Static hosting, edge API functions, and (once I wired it up) the database connection all lived in one deploy pipeline. If you've ever debugged a CORS or env-var mismatch between a frontend host, a serverless function provider, and a database vendor that don't share tooling, you'll get why that's worth mentioning.

If You're About to Build Something Similar

Decide your state/database approach before your first API route — not as a fix after deploying.
Check what happens to your database on inactivity, not just under load. "Free tier" often hides a failure mode in the fine print.
Use nullable foreign keys deliberately when your domain has "sometimes this relationship exists, sometimes it doesn't" — it's cheaper than modeling every variant as a separate table. OptiQ is live at optiq.logota.biz.id — built on Tencent EdgeOne Makers as part of Codepolitan's DevHandal 2026 Batch 2.

#TencentEdgeOne #EdgeOneMakers #CODEPOLITAN #EdgeOne

How a Broken Laravel App Turned Into Two Open Source Security Tools

Harry Agustiana — Mon, 13 Jul 2026 05:11:32 +0000

I now run a small self-hosted watchtower that pings me on Telegram the moment something looks wrong on any Laravel app I manage. It didn't start as a plan. It started with a friend's text message and a server that had already been compromised for who knows how long.

The app nobody thought was a target

The app was PaketLebaranku.id — a small Laravel + MySQL + Livewire platform running on a modest VPS through Biznet Gio, built for a friend's small business. Its only job: track installment savings for people paying into a Lebaran package program, small recurring deposits that add up to something meaningful once a year.

It's exactly the kind of app that never shows up in anyone's threat model. No enterprise budget, no dedicated ops team, no security monitoring — just a business owner and a friend who built the thing on the side. Which, as it turned out, is precisely why it got hit.

"The app is throwing a 500 error, can you check?"

That was the whole message. I expected a stack trace, maybe a bad migration or an expired dependency. Instead, digging into the error turned up something far worse.

The .env file wasn't misconfigured — it was gone. Any Laravel developer knows what that means: database credentials, app keys, third-party secrets, either already exposed or already pulled by whoever got in.

Then a second find: a handful of backdoor scripts sitting inside public/icons, dressed up to look like they belonged there. Then a third: .htaccess had been rewritten to let Python scripts execute inside a directory that should never be able to run anything.

Three separate footholds, sitting quietly in an app tied to real people's savings, for who knows how long before a user happened to hit an error page.

The gap that actually mattered

Once we'd contained it, the obvious question was "how do I catch this faster next time." But sitting with it longer, I realized the real failure wasn't a missing check — it was that nothing was watching at all. A scan run once, manually, after the fact doesn't help. The incident wasn't caught by a security tool; it was caught by luck, in the form of an annoyed user.

That reframed what I actually needed to build: not just something that could find this class of problem, but something that would look for it without anyone having to remember to ask.

Laravel Scalpel: the checks I wish had already existed

The first piece is Laravel Scalpel, a narrow, fast forensic scanner for Laravel codebases. It doesn't try to be a full SAST suite — it answers the exact three questions that would have shortened this incident from days to minutes: are there files sitting where they shouldn't be, does the environment configuration look right, are there permission or execution paths that shouldn't exist.

It's picked up some traction beyond my own use case — featured by the Laravel Artisan Community, 24+ GitHub stars, and a pull request currently open to get it listed in awesome-laravel.

N8N Bastion: making sure someone's actually watching

The second piece, N8N Bastion, is what closes the real gap. It's a self-monitoring stack built on n8n that turns infrastructure and application problems into a Telegram message — instead of a support ticket that arrives after the damage is done. Laravel Scalpel now runs inside it as a scheduled check, not a tool anyone has to remember to invoke.

Together they cover both halves of the problem: Scalpel knows what to look for on a Laravel app, and Bastion makes sure it's actually looking, on a schedule, without a human in the loop.

Why this is worth open-sourcing

PaketLebaranku.id will never make a breach headline. It's too small, too obscure, too ordinary — and that's exactly the point. There are a lot of small businesses running real, sensitive workloads on a single self-managed VPS with no monitoring at all, not because the owners don't care, but because every security tool out there quietly assumes a team and a budget they don't have.

Laravel Scalpel and N8N Bastion exist because of one real incident on one real app. I'm putting both out there because I'd bet a lot of other small Laravel apps are sitting exactly where PaketLebaranku.id was, right before that 500 error showed up.

If you run a Laravel app on a VPS you manage yourself, I'd genuinely like to know what breaks or what's missing if you try these:

Laravel Scalpel: https://github.com/hryagstn/laravel-scalpel
N8N Bastion: https://github.com/hryagstn/n8n-bastion