DEV Community: Nebosa Company

One tenant took the whole connection pool

Nebosa Company — Tue, 20 Oct 2026 07:00:00 +0000

Our tenant isolation was correct. Two tenants, separate realms, separate apps,
RLS confirmed both ways — the victim's token returns [] for the storm
tenant's table, and a script asserts it on every run. Nobody could read anybody
else's rows.

Then we pointed a load storm at one of them and the other one fell over.

The product tour, silent by design. Full-resolution video.

What we measured

Tenant A issued heavy 200-row reads at 60 concurrent. Tenant B issued the light
100-row read a grid does when you open it. Same stack, same database, 2,000
rows each.

phase	p50	p99	requests
baseline	3ms	31ms	200
under storm	3,194ms	10,007ms	200
recovered	3ms	5ms	100

Tenant B degraded 322× against a published bound of 2×, and 10.5% of its
requests were refused outright. The 10,007ms p99 is a timeout ceiling, not a
measurement — we never found out how slow it really was.

These are single-machine figures: Docker, the harness and the browser all on
one box. That is not a production result and we are not going to present it as
one. It is the right shape of measurement for the question — does one tenant's
load reach another tenant — and the wrong shape for "how fast is Appdor".

The part that made it obvious this was contention and not a bug: the storm
tenant's own throughput collapsed to 12.7 req/s. The instance did not throttle
one tenant in favour of another. It fell over for both. And recovery was
immediate — 5ms p99 the moment the storm stopped.

The mechanisms existed and nothing called them

This is the uncomfortable part. The fairness module was already in the tree.
It had tests. The only function of it the running product ever reached was the
one that publishes the promise to the capability catalogue.

A module that is imported by nothing on the request path is documentation with
a test suite. We had shipped the paperwork.

The fix was in-flight caps, not rate limits

The controller that now sits in front of PostgREST caps concurrent in-flight
work per tenant. That distinction is the whole result:

	before	after
victim p99 under storm	10,007ms	25ms
degradation	322×	well inside the 2× bound
victim requests refused	10.5%	0%

The "after" column is the 2026-09-07 re-run against the current gateway: 3,000
storm requests at 60 concurrent, two live tenants with tokens minted for
separate users. Baseline p99 28ms, under storm 25ms, recovered 15ms.

The defensible claim is "well inside the bound", not a specific ratio, and
that is deliberate. The same harness has returned 0.50×, 0.14×, 0.73× and 0.89×
across runs of unchanged code, because the ratio is computed against whichever
baseline the first phase happened to measure — and a cold stack measured 200ms
p99 where a warm one measured 44ms. A sub-1.0 ratio is evidence the baseline is
still warming, not evidence that a storm makes the victim faster. Quoting the
prettiest of those numbers would be the same species of mistake as the one this
post is about.

The storm's request rate was modest. Its concurrent count was the entire
connection pool. A token bucket would not have fixed this, and we can show that
rather than assert it: at the shipped 200/s limit the rate limiter absorbed
2,308 refusals; raising it to 5,000/s moved every one of those to the queue and
changed the outcome not at all — 85% shed either way. When you can move a
mechanism's threshold by 25× and the result does not care, that mechanism is
not the one doing the work.

A wider queue made it worse

We tried a 200-deep per-tenant queue on the theory that shedding less is
kinder. It converted refusals into waiting: the storm took 4.9 minutes instead
of 7 seconds, and the victim was still at 2.41× baseline when the run ended.
It failed the recovery check.

Refusing a request in 1ms is a better answer than serving it in 10 seconds.
Queues are how you turn a load problem into a latency problem and then lose
track of it.

What we still cannot claim

The criterion this was measured against is still marked unmet in our own
audit, and that is the most useful sentence in this post.

It asks for a sustained automation event storm and a public API burst,
simultaneously. The harness drives the burst only. So the measurement supports
a narrower claim than the criterion makes, and the honest version is "we fixed
the case we can drive" rather than "we meet the bar we set ourselves". The
audit row says so in the same words; we would rather you read it from us.

The other thing the ratio cannot tell you is why. A failure here says the
promise broke, not which mechanism broke it — that is what the per-tenant
gauges are for. A fairness number is a smoke alarm, not a diagnosis.

Why this is in a spreadsheet-database you run yourself

Appdor runs as one container you start yourself, so "multi-tenant" is not an
abstraction our SaaS operator worries about on your behalf — it is your
Postgres, your pool, and your two departments. The isolation you get from RLS
is about reading. Nothing in RLS stops one tenant from consuming the resource
every other tenant needs, and the failure looks like a slow app, not like a
security incident, which is why it survives so long.

The storm is a script in the repo:

npm run test:fairness

It fails loudly, in the direction of the number above, if the controller ever
comes unwired again — which is the only reason we trust it now, having already
been wrong once about a module that existed.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

Building a no-code app builder out of small pure modules, and testing each one on its own

Nebosa Company — Mon, 19 Oct 2026 23:35:54 +0000

I'm a solo founder based in Europe, building an app builder (Appdor) that turns a spreadsheet into a small business app. This post is about how the code is organised, because that choice has mattered more than any framework decision. Appdor is a plain JavaScript single-page app on Vite, with Postgres behind it. There is no UI framework doing the heavy lifting. What does the heavy lifting is a rule I set early.

The rule: every feature starts as a pure module

A feature like "sort and filter rows" or "evaluate a formula" begins as a function (or a small set of functions) that takes data and returns data. No DOM, no network, no globals. It lives in its own folder under src/ and has a mirrored test file. The thin layer that touches the page is written afterwards, and is deliberately dull.

Two examples from the repo:

The formula engine (src/formula/): a tokenizer, a parser, an evaluator and a function registry, each in its own file, plus a dialect layer that translates formulas written for other spreadsheets. Because the evaluator only sees values and a registry, a test can feed it a string and assert on the result. There is also a compiler that turns a subset of formulas into SQL, so the same expression can run on the server when the data is too big to bring to the browser.
The views engine (src/views/): sort, filter, group and summarise over an array of records. The grid, the board and the calendar all call the same function and differ only in how they draw the result.

Why this pays off

Tests are cheap, so they exist. A pure function needs no browser or mock server. The suite has thousands of tests and runs quickly because most of the code under test never touches a page.
The same module runs in more than one place. Validation, for instance, runs when you edit a cell, when you submit a public form and when you import a file. One implementation means one set of bugs.
The glue layer stays thin enough to read. The grid's cell editing is a good example. A small module decides how to coerce and validate what you typed; the DOM code just calls it and shows the toast.

Where it hurts (honest list)

One large file never got split. A single module, the main application file, grew into a tangle where about a third of the functions depend on each other in a cycle. Pure modules around it are tidy; the file itself is not, and extracting a function out of it is harder than it should be because one test suite loads parts of it as text.
Guard rails become part of the product. Several rules are enforced by tests that read the source: a bundle-size budget that fails the build, a check that every user-visible string has a translation key, and a check that new modules are actually imported from somewhere. They catch real mistakes, but they also fail for boring reasons, and they depend on the tree being stable when they run.
"Tested" is not "reachable". I once shipped a module with good tests that nothing imported. The suite was green, and the feature did not exist in the built bundle. Now there is a check that greps the output, not just the import graph.
Pure modules don't remove integration bugs. A date handed from one module to another in the wrong shape passes both modules' tests. You still need a few tests that go through the real glue, and a real browser run before you trust a release.

What I'd do again

Start with the data structure and the function that transforms it. Write the failing test with a hand-made input. Only then draw anything. When I broke this order, I ended up with logic buried in event handlers that I could only test by clicking.

What I'd do differently

Set a rule on day one that no file may import from a "god module", and ban "temporary" functions that hold state at module level. Both are cheaper to prevent than to remove.

If you build UI-heavy tools in plain JS, how do you keep logic out of the event handlers? I'd like to compare notes. (Appdor is at appdor.com if you're curious what these modules add up to; it's an early product from one person, with plenty of rough edges.)

Your Airtable formulas are the migration. Everything else is a CSV.

Nebosa Company — Tue, 13 Oct 2026 07:00:00 +0000

Getting your records out of Airtable is not the hard part. There is a button
for it and the rows come out fine.

The hard part is that a CSV export gives you what each formula column last
said, not what it means. Days to run arrives as 91 — a number, frozen, in
a column that used to update itself. Multiply that by however many formula
columns two years of use accumulated, across however many bases, and you have
the real migration: not moving data, but rebuilding logic from memory while
looking at the answers it used to produce.

The product tour, silent by design. Full-resolution video.

The failure is quiet, which is why it stalls migrations

It does not announce itself. The data lands, people start using the new tool,
and three weeks later somebody notices a column has been frozen since the
switch. Nobody knows which columns those are, because the export did not
distinguish a formula from a number. So somebody opens Airtable in a second
window and starts retyping expressions.

That work is unbounded and boring, which means it gets postponed, which means
the two systems run in parallel, which is how a migration reverts.

What actually happens to an Airtable formula

Appdor reads 7 formula dialects and compiles them into its own
expression language, so the expression moves and stays live. Here is what
that looks like on real formulas — left column in, right column out:

Airtable	Appdor
`IF({Status} = "Done", 1, IF({Status} = "Blocked", -1, 0))`	`IF({Status} = "Done", 1, IF({Status} = "Blocked", -1, 0))`
`DATETIME_DIFF({Due}, {Start}, 'days')`	`DATETIME_DIFF({Due}, {Start}, "days")`
`DATETIME_FORMAT({Due}, 'YYYY-MM-DD')`	`DATETIME_FORMAT({Due}, "YYYY-MM-DD")`
`ROUND({Hours} * 145, 2)`	`ROUND({Hours} * 145, 2)`
`SWITCH({Tier}, "Priority", 2, "Standard", 1, 0)`	`SWITCH({Tier}, "Priority", 2, "Standard", 1, 0)`
`REGEX_EXTRACT({Project}, '^[A-Z]{3}')`	`REGEXEXTRACT({Project}, "^[A-Z]{3}")`
`ARRAYJOIN({Tags}, ", ")`	`JOIN({Tags}, ", ")`
`RECORD_ID()`	`ROWID()`
`CREATED_TIME()`	`CREATEDON()`

Two things are worth noticing, and neither is the flashy one.

The first five rows are boring: the nested conditional, the date arithmetic,
the rounding and the SWITCH come across effectively unchanged, with quoting
normalised. That is the common case, and the common case being boring is the
entire product claim.

The last four are the interesting ones — REGEX_EXTRACT loses its underscore,
ARRAYJOIN becomes JOIN, RECORD_ID becomes ROWID, CREATED_TIME becomes
CREATEDON. These are the ones a person retyping by hand gets wrong, because
they look fine either way and only fail at evaluation.

What it refuses to do

Some Airtable functions have no counterpart, and the compiler says so rather
than guessing. PREVIOUS_VALUE({Status}) depends on Airtable keeping the prior
value of a cell — a model Appdor does not have — and it comes back like this:

Unknown function "PREVIOUS_VALUE" in dialect airtable.

A formula that does not parse at all gets a position, not a shrug:

Could not parse airtable formula: Unexpected character '@' at position 28

That list of refusals is your actual migration backlog, and it is normally far
shorter than the inventory of formula columns. It is also the part worth
insisting on when you evaluate anything else in this category: a migration
tool that reports no losses has not found none, it has stopped looking.

The rest of the base moves too, and it also reports

Formulas are the headline, but they are not the only thing a CSV drops.

Linked records. A link cell holds Airtable's own rec… ids, and those mean nothing once rows have new ids. So the import runs in two passes: write every row, build a map of old id to new id, then go back and rewrite the links. Doing it in one pass is the obvious implementation and it silently produces a base where every cross-record link points at nothing.
Saved views. Filters and sorts are rebuilt against the new columns. A clause that cannot be expressed is not dropped quietly — in a real run, a view filtered on a checkbox lost its clause and arrived showing every row, and the report raised it as blocked rather than as a note. A view that arrives unfiltered shows more rows than it should, and for a view somebody shares, that is a disclosure rather than a cosmetic loss.
Buttons, interfaces and automations. These have no equivalent. The button arrives as text, and the report says the type had no equivalent rather than leaving a column that looks right and does nothing.

Both import routes show you what they are about to do before anything is
written, and both name what they could not carry — the formulas they
translated, the field types that fell back to text, and the ones that failed
outright. They are not identical: the pasted-export route ends in a full
fidelity report that sorts every column into carried exactly, approximated,
unsupported or dropped, and adds findings about saved views and relationships
that the token route's preview does not raise. Both tell you where the losses
are; one of them is more thorough about it.

The order that works

Inventory the formula columns before you migrate, while you still have the old system to read. This is twenty minutes and it is the step people skip.
Import and read the report. Nothing is written until you have. The refusals list is the backlog; the blocked items are the ones that change what people see.
Rebuild the refusals by hand. There will be some. There are always some.
Diff a sample of computed values against Airtable before you switch anyone over. This is the only step that proves the migration worked, and it is the other one people skip.

How the import gets your base

For completeness, since this is the question every thread about this asks: you
make a read-only personal access token in Airtable — schema.bases:read and
data.records:read — paste it into Settings → Import, and Appdor lists your
bases so you can pick one. The token goes straight to the server and never
stays in your browser; it is discarded after the request unless you ask us to
remember it, in which case it is encrypted at rest and only its last four
characters are ever shown back to you. There is no OAuth flow and nobody should
tell you there is one click.

There is also a paste route, for a base you no longer have access to or an
export somebody sent you.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

Your data should outlive my company

Nebosa Company — Tue, 06 Oct 2026 07:00:00 +0000

On 4 August 2026 Airtable was bought by Bending Spoons for $1.285bn.

I am not going to tell you what happens to your bill. I don't know, and neither
does anyone else writing about it. What I will say is that the
acquirer has a public record: Evernote went from 341 people to 60 inside twelve
months and the free plan was curtailed; WeTransfer saw staff cut and free limits
tightened; TechCrunch traced the same cycle across five of their purchases.

I build a competing product, so discount me accordingly. But the question stands
whether you ever talk to me or not, and it isn't really about Airtable. It's
this: if the company holding your operational data changed its mind about you
tomorrow, what would you actually do?

For most teams the honest answer is "export a CSV and hope." That is the problem
I have spent this year on.

The product tour, silent by design. Full-resolution video.

What "keep your own data" has to mean

It is a phrase every vendor uses and almost none of them mean, because meaning
it is expensive. Here is the version I hold myself to.

It has to run without me. Not "we offer an enterprise self-hosted tier." Not
"contact sales." The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

One container: the database, the API and the app together. Thirty days on the
Business tier, then a licence — a signed file checked against a key inside the
image, so nothing phones home to ask my permission to keep working. If I am hit
by a bus, the licence you hold keeps working until the date printed in it, and
your data stays readable and exportable after that with no licence at all.

It has to be truthful about telemetry. There is a crash reporter and there
are product analytics in the box. I would rather describe that accurately than
write "no telemetry" and have you find the consent banner yourself. The crash
pipeline stays inert until you set a key. The analytics ask first, honour Do Not
Track, and post to your own instance rather than to me. The prompt the product
actually shows on first run says it records page names and actions — never your
data, never your record contents — and if you press No thanks, nothing is
recorded and it does not ask again.

It has to be checkable rather than promised. Two scripts ship in the box:

bash scripts/rls-test.sh
bash scripts/tenant-isolation-test.sh

The second one proves two tenants cannot see each other in both modes — shared
database and database-per-tenant. You run it against your own install. You don't
take my word for the isolation, and you shouldn't.

The product this is attached to

None of the above matters if what you are self-hosting is a toy. The application
I use to test this is a plant-wide manufacturing ERP: employees and gate entry,
shifts and vacation, working stands, SOPs, items, bill of materials, warehouses
and inventory, suppliers, purchase orders, customers, sales and production
orders, quality, repairs, forwarders and shipments. Twenty-two pages, eleven
workflows, one workspace.

Four things in there worth a technical reader's attention.

Field types that refuse bad input

Your database lets you type an IBAN wrong. So does every spreadsheet-shaped tool
I have compared against — they store it as single-line text and hope, and you
find out the money is gone about a week later. There are 90 field
types here and 59 of them refuse malformed input by format
or checksum.

Eleven of those are enforced in the database itself rather than in the browser:
IBAN and LEI by ISO 7064 mod-97, ISIN and card numbers and IMEI by Luhn, the VIN
transliteration, ISBN-10, ISBN-13 and the bare ISBN, EAN-13, UPC. Those hold
when the row arrives through the REST API, a webhook, or an importer at 3am with
no browser in the loop.

The rest — VAT, MIC, ICD-10, SNOMED, NDC, HS codes, UN/LOCODE — validate as you
type, and that is deliberate rather than unfinished. Their rules are national
registries and revisable code lists. A regex that is subtly wrong at the
database level rejects a real customer's valid identifier with no way around it.
A mod-97 cannot be subtly wrong. Narrow and correct beats broad and approximate
on the write path.

A dashboard is just a page

There is no separate BI product bolted on the side. A page is a stack of
elements, and there are 48 of them — table, list, gallery, kanban,
calendar, chart, form, gantt, timeline, pivot and the rest. You drop a number
tile on a page, point it at a table and an aggregate, and that is your
dashboard. The morning-meeting screen for the ERP above is three number tiles
and a chart: order book, output and stock, on one page.

Every chart type and every view is on the Free tier. That is an easier promise
to keep when the charts are not a separate product with their own margin to
defend.

Automations you can audit

Rules are the part of a low-code tool that rots quietly. Somebody builds one,
leaves, and two years later nobody can say what fires, or whether it still does.

So the workflow list is workspace-wide rather than buried one table at a time.
Each rule shows its trigger, its condition, the app and table it belongs to,
whether it is on — and the part I care about most, whether it has ever run.
"Never used" is a badge on the row, not something you go digging through logs to
work out. The rules marked that way are the ones worth deleting, and the page
turns that into a five-second judgement instead of an afternoon.

A seam for agents instead of a fight with them

"AI will make no-code obsolete" is half right: generating an interface is nearly
free now, and the moat no-code had in 2019 is gone. The half that is not right
is that your data still has to live somewhere — with permissions, with a backup
you have actually tested, with something stopping the malformed row, with an
audit trail when someone asks who changed the price. AI does not remove that. It
makes it easier to skip until it hurts.

So there is an MCP server in the box, over stdio and HTTP. Your database becomes
a tool the agent holds, scoped by row-level security, rather than something
reached through a scraped API key.

The AI meter I deleted

On the 4th of August I deleted our AI billing meter. Not disabled — deleted.
There is no credit balance in the product, nothing to debit, and no code path
that can refuse your AI call to protect my margin.

To be precise, because someone will eventually read the code and I would rather
they find me accurate than clever: usage is still recorded. Which model ran,
for which feature, on whose behalf, and how many tokens your provider counted.
That row exists so an admin can check it against their own provider invoice.
Recording is not metering — nothing in that row decides whether your next
operation is allowed, and no number in it is a price.

The reason is that I could not find an honest version of the alternative. Every
AI credit pack I priced came out as a markup on someone else's model, dressed up
as a feature. You would be paying me to pass your prompt along. So instead:
bring your own key. Your provider, your rate, your bill. I never see it and I
take no cut, on every plan including Free.

The one thing that can stop an AI call is a spend cap you set and you raise, so
a runaway workflow cannot burn through your provider key at 3am. I do not earn a
penny from it firing.

This removes a revenue line most of my category treats as core. I would rather
explain that to an investor than explain a credit pack to a customer.

What I don't have

I am one engineer, and the fastest way to lose a technical reader is to let them
discover a gap I hid.

We are not SOC 2 certified. Not ISO 27001. No HIPAA BAA. The test suite
fails the build if those words appear on the homepage, which was deliberate. If
a certificate is a hard gate for you this quarter, I am the wrong call this
quarter, and I will tell you that on the first call rather than the fifth.

What exists instead is measurement, and you can read the recordings:

Run	Result	Measured
Disaster recovery	RTO 9.4s, RPO 120 rows, restore verified by checksum	1 August, due a re-run
Noisy-neighbour fairness	One tenant under a 3,000-request storm from another ran at 0.89x its own quiet p99	September 2026
Load	p50 37ms, p99 43ms, zero errors over 500 requests	September 2026

An older load run on a smaller database read p50 6ms. I am quoting the slower
number because it is the current one.

The repository is private while this is early. So "run the isolation test
yourself" today means asking me for access rather than a public clone. That is a
decision I intend to reverse, not a permanent one, and I would rather say it
plainly than link you into a 404.

It is one person. That is the risk you take on, and it is exactly why the
self-hosted path above is not a marketing tier. It is the answer to the obvious
objection.

If you want to look

There are no seat minimums, no charge for read-only viewers, no charge for the
people who use the apps you publish, and no view or chart type held behind a
tier.

If you are weighing a move this quarter, the useful ten minutes is not reading
this post — it is opening your current bill and counting how many editors you
pay for versus how many actually edit. Almost nobody knows that number offhand.

And if you want to test the switching cost rather than guess at it: send me your
gnarliest formula from Airtable, monday, ClickUp, Smartsheet, Quickbase, Notion
or AppSheet. 7 dialects are understood inbound, 279 functions on this
side to land them in. I will paste it in and screen-record what happens —
working or not. I will show you the failures too. Those are more useful to me
than the wins.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

The seat minimum is a pricing decision, and you are paying for it

Nebosa Company — Tue, 29 Sep 2026 07:00:00 +0000

Here is a thing that is easy to miss when you compare pricing pages: the number
on the page is the rate, not the bill.

Two of the biggest tools in this category will not sell you exactly the number
of seats you have.

The product tour, silent by design. Full-resolution video.

monday.com sells in blocks of five, with a floor of three

The Pro plan is $19 per editor per month. But the smallest purchase is
3 seats, and above that it is sold in blocks of 5.

So if your team is six people, you do not buy six seats. You buy ten.

Editors you have	Seats monday bills	Monthly	Effective rate per real editor
1	5	$95	$95.00
6	10	$190	$31.67
11	15	$285	$25.91
16	20	$380	$23.75

Every one of those rows is a real invoice, and every figure in the table came
out of the function our own pricing page bills against rather than out of my
head. At six editors you pay for ten at $19 each, so the rate per person
you actually have is $19 on the pricing page and $31.67 in practice —
67% higher.

Note the first row. The floor is 3 seats but the block size is
5, so a single editor is rounded up to 5 rather than
to the floor. The two rules compound; they do not overlap.

Quickbase will not sell you fewer than twenty

The Team plan is $35 per user per month with a floor of
20 users. That is the entry price of the product, and it is the
entry price whether you are twenty people or three.

For a team of five evaluating it, the pricing page says $35 and the
invoice says $700 a month — 20 seats at $35,
four times the people you have. That is not a trick; it is on their page. But it
is the number that decides whether you can pilot the thing, and it is not the
number anyone quotes in a meeting.

Why vendors do this

Not out of malice. Seat floors and buckets do three things for a vendor:

They raise average contract value without raising the advertised rate, which is the number that gets compared.
They make small accounts profitable to support.
They create a step function, so growth produces revenue in jumps rather than smoothly.

The third is the one to watch, because it means your bill moves when you hire
your eleventh editor and does not move when you hire your twelfth.

What Appdor does

No minimum, and no buckets. You are billed for the editors you have, viewers are
free and unlimited, and the plan does not decide which of the product you may
use — all 48 page elements, 25 chart types and
24 dashboard widgets are in every tier.

⚠️ That is a pricing commitment, not a claim of being cheapest. For a large team
on an annual deal, a competitor's negotiated rate may well beat our list price.
What we are saying is narrower and checkable: you will not be invoiced for
seats you do not have.

If you want the comparison for your own headcount rather than a table of
somebody else's, the migration calculator on the pricing page does the
arithmetic — including the floors and the buckets, because a saving computed
against the advertised rate rather than the real invoice would be the same
sleight of hand this post is about.

The wider point

Seat rules are the clearest example of something true across this whole
category: the pricing page is a marketing surface and the invoice is the
product. When you evaluate any of these tools, price the invoice for the team
you actually have, at the size you expect to be in a year, with the features you
will actually need — and check which of those features is a tier.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

The container was running software nobody built

Nebosa Company — Tue, 22 Sep 2026 17:08:24 +0000

A deploy that silently does nothing is worse than a deploy that fails, and we shipped two flavours of it before either one announced itself.

The first one: a deploy with an expiry date

The fast dev loop is to tar a built dist/ into /usr/share/nginx/html of a running container. It works. The page updates, the change is live, and the loop is seconds instead of minutes.

It survives docker restart. It does not survive a docker compose up -d that recreates the container, because the new container comes up from the image, and everything deployed that way reverts to whatever the image was built with.

Nothing errors when this happens. No log line, no failed request; the app simply becomes an older app, and every measurement taken afterwards is of software nobody built.

It cost one session a reskin, a glyph set and two bug fixes on 2026-08-27. It was noticed only because the served bundle hash changed — not because anything complained.

The second one: a recreate is not a rebuild

The subtler version has no hot-patching in it at all.

Measured the same day: the running image had been built the previous evening and carried 19 supervisord programs against the tree's 20. The missing one was cert-watch, the certificate-expiry watcher. So on a deployment serving portal custom domains, the alarm for a certificate about to expire was not running — and the image's own healthcheck was one probe short of being able to notice that it wasn't.

The instinct here is --force-recreate, and it does not help. It recreates the container from the same image. Only docker compose build produces a new one. The distance between those two commands is one word, and the feedback that tells them apart is nothing at all: docker ps, docker inspect and the health status all look identical either way.

Why "it looks fine" is not evidence

Both failures share a shape worth naming, because it generalises past Docker.

A deployment has two states that present identically to every casual check: running what you built, and running something older that still starts cleanly. Nothing in the second state is broken enough to complain. The process is up. The healthcheck passes — it is the old healthcheck, and it passes honestly. Requests return 200. The only difference is that the thing answering them is not the thing in your tree.

The measurement is what gives the game away, in both directions. A bundle budget that improved without anybody optimising anything. A test that started passing without anybody fixing it. Both of those are the same report: you are measuring a build you did not make.

What we do about it

Three things, none of them clever.

Name the fast path as a dev loop, in the script itself. scripts/deploy-to-container.sh opens with the line NOT A DEPLOY. See docs/deployment.md — a release is an image. This is the dev loop. A comment is not a gate, but the cost of this failure is entirely in the belief that a deploy happened, so the belief is what to attack.

Have a command that answers "what is actually running". node scripts/env-preflight.mjs diffs the container's [program:] set against docker/supervisord.conf and names the programs that are missing. That is the check that catches the 19-against-20 case, and it exists because nothing in Docker's own output does.

Give the database question its own tool, with three outcomes. npm run ops:drift compares the init files against the database you are serving from, and it reports IN SYNC (0), DRIFT (1) or NOT MEASURED (2) when the database could not be read. The third one matters more than it looks: an unmeasured state must never be readable as a good one. Most tooling folds "I couldn't check" into "fine", which is how you end up trusting a green light that was never on.

The rule this leaves us with

If you recreate the container, redeploy. And if a number moves in a direction nobody worked for, check which build is serving before you believe it.

That is not a Docker lesson. It is what happens any time the artefact you deploy and the artefact you edit are two different objects, and only one of them is on screen.

Appdor vs Airtable: the same job, a different bill and a different address

Nebosa Company — Tue, 22 Sep 2026 07:00:00 +0000

Airtable made this category. If you are reading this you have probably built
something real in it, it probably works, and the question is not whether
Airtable is good software. It is whether the two things it cannot change about
itself matter to you.

Those two things are where your rows live and what the second year costs.

The product tour, silent by design. Full-resolution video.

Where the rows live

Airtable is a hosted product. Your data is in their infrastructure, and the
answer to "which sub-processors touch our production records" is their list, not
yours.

Appdor is a work OS that sits on top of a Postgres database rather than
inside a vendor's. The database is the system of record, it is ordinary
Postgres, and you can point psql at it. The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

For a lot of teams that difference is worth nothing, and I would rather say so
than pretend otherwise. It becomes worth something the first time a customer
contract names a jurisdiction, an auditor asks for the schema, or somebody wants
a read-replica for the warehouse team.

What the second year costs

This is the part that surprises people, because it is not the sticker price.

Airtable's Team plan is $20 per editor per month on annual billing;
Business is $45. The jump between them is the interesting number:
it is a 125% increase, and the features that force it — field-level
permissions, SAML, admin controls, more records per base — are the ones a team
needs precisely when it has stopped being a pilot.

	Airtable	Appdor
Entry paid tier	$20 per editor / month	see the pricing page
Next tier up	$45 per editor / month	one step, not a cliff
Views behind a plan	Gantt and timeline are paid tiers	all 12, every plan
Charts behind a plan	extensions vary by tier	all 25, every plan
Records per base	capped, and the cap is a tier feature	your Postgres
Read-only viewers	free	free
Self-hosting	not offered	the same build you would pay us to host

The row that matters most is the one about views. Appdor ships 12 view
types, 48 page elements, 25 chart types and
24 dashboard widgets, and none of them is a plan tier. The
plan decides seats, support and who runs the servers. It does not decide which
of the product you are allowed to use.

What Airtable does that we do not

A comparison post that finds nothing good to say about the other product is an
advertisement, so:

The ecosystem. Airtable's marketplace, its extension gallery and the sheer number of people who already know it are real advantages, and a smaller product does not have them.
Interface Designer is mature and has had years of polish.
Sync from other bases is a first-class feature there.

If those are load-bearing for you, that is a reasonable reason to stay.

The migration, honestly

Your rows will move. Every tool in this category exports CSV and the rows come
out fine.

What does not come out is the logic — the formula columns are the part that
stalls migrations, because an export gives you the last computed value and loses
the expression that produced it. Appdor reads 7 competitor formula
dialects, Airtable's among them, and recompiles the expression rather than
freezing its output. That is covered properly in its own post.

It is not a promise that every expression survives. A function with no
counterpart is reported rather than guessed at, and that list of refusals is
your real migration backlog.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

What happens when the vendor changes the deal

Nebosa Company — Fri, 18 Sep 2026 14:13:12 +0000

In January 2026 SmartSuite withdrew its free plan. Existing free workspaces kept
working until July, and then they expired.

I want to be careful here, because this is the kind of story that gets told
unfairly. SmartSuite did nothing dishonest. They gave six months' notice, the
plan was free, and no company owes anyone a free tier forever. Their paid plans
start at $30 per editor per month for Professional and the
product is well regarded.

The point is not that they behaved badly. The point is that it was entirely
their decision to make, and everyone whose team ran on that plan found out
what that meant on the same day.

The thing you are actually buying

When you adopt a hosted work OS you are buying two different things and only one
of them is on the pricing page.

The first is the software: views, automations, formulas, permissions. That is
what you evaluate.

The second is a standing dependency on someone else's commercial decisions —
their pricing, their packaging, their roadmap, their acquisition, their
continued existence. That one is not on the page, has no SLA, and is the one
that decides whether the thing you built is still there in three years.

Nothing about this is unique to SmartSuite. In the last few years this category
has produced:

free tiers withdrawn;
entry plans repriced;
features moved up a tier, so the same workflow costs more without changing;
AI sold as a separate meter on top of the seat you already bought;
companies acquired, and their products folded into someone else's roadmap.

None of that is misconduct. All of it is a vendor doing what a vendor is allowed
to do with a product it owns and hosts.

The product tour, silent by design. Full-resolution video.

What changes if you can run it yourself

Appdor is a work OS on top of a Postgres database rather than inside a vendor's.
The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

That does not make us immune to being a company that makes decisions. We can
change our pricing too. What it changes is what happens to you if we do:

The database is ordinary Postgres and you can point psql at it. Your data does not need our cooperation to be readable.
The build you self-host is the same build we host, on the same plans. There is no licence server to call and no activation: a licence is a signed file checked offline against a key inside the image. Thirty days to try it, then a licence to keep editing — and reads and exports never lock.
Nothing is behind a plan. All 48 page elements, 25 chart types and 24 dashboard widgets ship in every tier, so there is no ladder for a feature you already use to be moved up.
If you want to leave, the exit is a pg_dump rather than a support ticket.

⚠️ That is a smaller claim than "you are safe", and I would rather make the
smaller one. Self-hosting moves a risk; it does not delete it. You now own
backups, upgrades and uptime. For a lot of teams that trade is not worth it, and
the hosted option exists for exactly that reason.

The question to actually ask

Not "is this vendor trustworthy". They usually are, and it does not help you
anyway — the SmartSuite decision was made by people acting reasonably.

Ask instead: if this vendor changed the deal tomorrow, what would it cost us
to say no?

For most hosted tools the honest answer is "a migration we do not have time
for", which is another way of saying the deal cannot be refused. If the answer
is "we keep running the build we already have, on our own hardware, while we
decide" — that is a different position to negotiate from.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

Your spreadsheet-database can run on hardware you already own

Nebosa Company — Fri, 18 Sep 2026 14:11:14 +0000

Every spreadsheet-database product on the market will tell you your data is
safe. Almost none of them will tell you where it is.

That distinction stops being philosophical the first time somebody in
procurement asks which sub-processors touch your production records, or the
first time a customer's contract says the row has to stay inside a particular
jurisdiction. At that point "safe" is not an answer. "It is in a Postgres
instance on hardware you control, and here is the connection string" is.

The product tour, silent by design. Full-resolution video.

What running it yourself actually means here

Appdor is a work OS that sits on top of a Postgres database rather than
inside a vendor's. The database is the system of record, it is ordinary
Postgres, and you can point psql at it.

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

That is the whole installation. There is no licence server to call and no
activation step: a licence is a signed file, checked against a key that is
already inside the image, so nothing phones home. You get thirty days on the
Business tier to decide; after that the install keeps every read and every
export but stops taking edits until a licence is in. What it never does is
quietly switch a feature off because it noticed it was running outside a
hosted plan.

The consequences are worth being precise about, because "self-hostable" is a
word that has been used loosely enough to mean nothing:

The schema is yours. Tables are tables. A migration you write by hand, a read-replica you attach, a nightly pg_dump into your own object store — all of it works, because there is no proprietary storage layer between the product and the database.
The product does not phone home. No telemetry endpoint and no licence check. The application and marketing bundles are served from the origin you deployed — no CDN. One exception, stated because you would otherwise find it in a network tab: the Map element fetches its basemap tiles from OpenStreetMap's servers by default, which tells that host a viewer's IP address and roughly where they are looking. It is one setting (tileUrl) pointed at your own tile server, and nothing else changes.
Nothing is gated. All 48 page elements, 25 chart types and 24 dashboard widgets are present in the build you just started. There is no plan that unlocks them.

The part that usually breaks

Most migrations off a hosted spreadsheet-database do not fail on the data. They
fail on the logic — the several hundred formula cells somebody wrote over
three years, in a dialect that only exists inside one vendor's product.

Appdor reads 7 formula dialects and transpiles them into its own. That
is a separate piece of work with its own article, but it is the reason this
particular migration is finishable rather than merely startable.

What you should check before believing any of this

Reasonable scepticism about a self-hosting claim looks like this, and all four
are things you can verify yourself in about twenty minutes:

Bring it up with the network disconnected after the images are pulled. If it needs the internet to run, that is where you will find out.
Connect to the database directly and read a record you created in the UI. If you cannot, the storage is not really Postgres.
Grep the built assets for absolute http(s) URLs. Third-party requests are not a matter of policy; they are a matter of fact.
Turn off a feature's network path and see whether the feature admits it.

The fourth is the one that separates products that are honest from products
that are merely quiet.

Where this leaves you

If you are running a spreadsheet-database today and the answer to "where does
this row live" is a vendor's region list, you have a dependency you did not
choose and cannot audit. Running the same class of tool on your own Postgres
turns that into a deployment decision — which is the kind of problem your
infrastructure team already knows how to have.

The product is free to run on your own hardware, and it is available in
36 languages.

Originally published at appdor.com. I build Appdor, so weigh accordingly.