Changelog
What changed in each release, in terms of what you would notice using it.
v3.3.1
September 16, 2026you are running thisA media field stores the file’s URL, as v1 did, so a site reading the field gets an address it can use.
Added2 changes
- expand resolves a media field either way: a URL is matched against the library, so v1 records and records saved by the form expand alike. A URL that names no file in the library is omitted.
- Media listings and the single-file endpoint include publicUrl, the stable address written at upload, distinct from url, which may be a time-limited signed link.
Changed2 changes
- Picking a file in the record form stores its URL — the address recorded at upload — rather than its id, which is what v1 wrote and what a site reading the field directly expects. A file with no recorded address falls back to the id.
- A media field accepts a file URL or a file id, alone or in a list. Relations are still ids only.
v3.3.0
September 16, 2026Media fields expand to the file they point at, wherever they sit, and the record form’s media picker shows the pictures.
Added2 changes
- expand on a media field returns the file — id, filename, mimeType, size, directory, url, createdAt — under the record’s "expand" object, next to expanded relations. ?expand=* now covers media fields too.
- Naming a component or dynamic zone field in expand resolves the media fields inside it: the component object, or each zone instance’s data, gains its own "expand" object, so a page built from blocks gets its image URLs in the same request.
Changed1 change
- Fetching one media file when storage is not configured returns its metadata with a null url, as the listing already did, instead of an error.
Fixed1 change
- The media picker in the record form shows image thumbnails instead of a bare list of filenames, and the chosen file stays visible as a thumbnail with its name — including when you reopen a saved record, which previously showed only the tail of an id.
v3.2.2
August 26, 2026Uploaded files keep their own names, so a media URL reads like the file it points at.
Changed2 changes
- An uploaded file is stored under its own name — /blogs/social-listening/instagram-2026.png — rather than behind a generated id, which is how v1 wrote them and how a link in a post is meant to read.
- A name already in use in that folder gains a counter, hero-1.png, instead of overwriting what is there: without the generated id, two people uploading the same filename would otherwise take each other’s files away.
v3.2.1
August 24, 2026The media library opens on every project, its URLs point at files that exist, and uploads are recorded in the shape the client’s own site already reads.
Changed2 changes
- When a bucket refuses an upload, the reason it gave — wrong region, missing permission, no such bucket — is shown instead of “Something went wrong”, and the endpoint it was sent to is written to the server log.
- Uploads are recorded with the project, the original filename, the public URL and the upload time — the same fields v1 wrote — so a site reading the media collection directly picks up new uploads without any mapping.
Fixed4 changes
- Uploads to an AWS bucket outside us-east-1 work. The endpoint was pinned to whatever was typed — usually s3.amazonaws.com, which is the us-east-1 host — so every request for a bucket in another region was refused; AWS buckets are now reached at their own regional address, derived from the region in settings.
- The media library opens on projects that have two or more folders side by side. The folder grid sorted by a name the folder listing does not send, which failed in the browser before anything rendered.
- Copy URL and image previews in the media library include the bucket in the address. A public base URL naming the storage host alone produced links without it, which the storage server answers with a 404.
- The media listing sorts newest-first for migrated libraries too, instead of grouping every record whose upload time was written by an earlier version at one end.
v3.2.0
August 12, 2026Complete documentation: a guide for every module, from getting started to integrations, served on the website.
Added1 change
- Guides for every module at /docs — getting started, schemas & records (with the full query language), endpoints, events, auth schemas, forms, media, access, and integrations — cross-linked and included in the sitemap automatically.
v3.1.0
August 12, 2026A proper identity and a proper website: a real logo everywhere, a favicon, richer landing content, and search-engine plumbing.
Added3 changes
- A real logo — an E drawn as a flow pipeline — used across the dashboard, auth pages and website, with a matching favicon.
- The landing page answers the questions people actually ask — ownership, stack requirements, what happens if you leave — in a proper FAQ.
- Search-engine plumbing: sitemap, robots rules, canonical URLs, social-share metadata and structured data for the product and FAQ.
v3.0.1
August 12, 2026Media libraries migrated from v1 get their folders back: directories embedded in old filenames are recognised everywhere folders appear.
Fixed2 changes
- Folders stored the v1 way — as a prefix inside the filename, like blog/photo.jpg — now appear in the media library’s folder list, their files are filed under them instead of flooding the top level, and filenames display without the prefix.
- v1’s zero-byte .directory placeholder files are treated as folder markers: they keep an empty folder visible but no longer show up as files.
v3.0.0
August 12, 2026Custom API development: events grow into multi-step flows with chained outputs and conditions, and projects can define their own request-to-response endpoints powered by the same flows.
Added15 changes
- Flow steps in events: query, create and update records, make HTTP requests whose responses feed later steps, and add conditions that stop a flow early. Each step’s output is available to later steps as {{steps.<name>.<path>}}.
- Custom endpoints: define your own API route (method + slug) whose logic is a flow and whose JSON response is a template over the flow’s outputs — callable publicly with rate limiting, with an API key, or by a logged-in end user of an auth schema.
- A visual flow editor for events and endpoints: steps on a canvas, configured in a side panel, with the run order always explicit.
- Endpoint permissions: endpoints.read/create/update/delete for management, and a separate endpoints.invoke so an API key can be allowed to call endpoints without being able to read or rewrite them.
- Endpoints can allow browser calls from your site: per-endpoint CORS origins, with preflight handled automatically.
- Endpoint responses are fully shapeable: any status, a content type (HTML, XML, CSV, plain text — not just JSON) and custom headers, enabling pages, RSS feeds and sitemaps served straight from a flow.
- Public GET endpoints can cache their responses for up to an hour — repeated calls stop hitting your database, and editing the endpoint clears its cache immediately.
- A Test run panel in the endpoint editor: run the draft flow against a sample request and see each step’s result and the rendered response before saving.
- Templates can read an array’s size — {{steps.<name>.length}} renders the number of records a step returned.
- Query steps can expand relations — “articles with each author embedded” is one step, using the same expander as the records API.
- A Transform step (JMESPath) for real multi-schema composition: filter, join and reshape the outputs of earlier steps declaratively — no user code, no side effects.
- Relation values are verified to reference records that actually exist — a typo’d or stale id is rejected with a per-field error instead of storing a dangling reference.
- Endpoints can be organised into named groups — the list renders one section per group, and the editor suggests existing group names.
- A documentation section at /docs, starting with a full Endpoints guide — the header help icon opens it, and the endpoints page links straight to its guide.
- Inline ? hints on the trickier endpoint and flow editor fields — hover or focus one to see what the field does and when to use it.
Changed2 changes
- The home page is now a real landing page — what the platform does, how it works, and a live-style picture of a flow — with signup as its closing section instead of the whole page.
- Event execution logs now record each step’s name and a preview of its output, so a failed automation shows where it stopped and what it had computed.
Security1 change
- Unique fields are now backed by real database indexes (nulls exempt), so two simultaneous writes can no longer both slip past the uniqueness check. Best-effort on legacy data that already contains duplicates.
v2.0.0
August 12, 2026A ground-up rebuild as a multi-tenant platform. Each workspace lives on its own subdomain, and every project connects to a MongoDB the client owns rather than to a shared database.
Added14 changes
- Multi-tenant workspaces: a subdomain resolves to a workspace, and each project connects to a database the client supplies and controls.
- Platform admin console — workspaces, projects, owners, statistics, and an append-only audit trail of every administrative action.
- Workspace rename, covering both the display name and the subdomain, with the change recorded in the audit trail.
- A full record query language: page, limit, search, sort, expand, fields, omit, filter[field], filter[field][operator] and exactFilter, on both the list and single-record endpoints.
- Relation expansion — expand=author or expand=* populates related records in one query per target schema.
- Generated API documentation per schema, with query parameters, response shapes, an error reference and copyable examples written against that schema’s own fields.
- Events: automations triggered manually or by record and form activity, running webhook and templated-email actions, with an execution log.
- End-user authentication schemas, so a client’s own customers can sign in to their site. CORS is restricted to the application URL rather than open.
- Media library backed by the client’s own S3-compatible bucket, with image thumbnails in the grid.
- Row selection and bulk delete on records.
- API keys with per-key permissions, stored as bcrypt hashes and shown once at creation.
- A published data-handling page at /privacy listing every collection on both sides, and what stays in the client’s own database.
- Version reporting on the project overview, the admin overview, the sidebar and /api/health.
- Unsaved-changes protection when leaving a half-edited record.
Changed5 changes
- Validation failures now report which field failed. The API returns per-field issues and the form shows each message beside its input instead of one sentence at the top of the page.
- Sorting uses the -field convention (sort=-createdAt). The older sort= plus order= form still works.
- Default page size is 10, previously 25. The maximum remains 100.
- The project settings page shows which database is attached, with credentials stripped, rather than an empty field.
- Required fields, uniqueness and field types are enforced server-side. In v1 they described intent rather than a guarantee.
Fixed6 changes
- Records are read from schema_<name>_records, matching v1’s layout. Migrated projects had content that the application could not see.
- Dynamic zones resolve components stored under any of v1’s three key spellings, fixing “Model "" not found” on imported data.
- URL fields accept relative paths such as /shop, which v1 permitted.
- Failed saves on the settings page are shown next to the form that failed. They were rendered in a banner far above the viewport, so a rejected save looked like nothing had happened.
- The event execution log reports why it could not load instead of doing nothing, and is indexed so it keeps working as it grows.
- Clearing the API documentation cache clears the entry that is actually being served.
Security7 changes
- Email and integration endpoints now require permission. They were reachable by any project credential, including an API key issued with no permissions — which allowed sending mail through the project’s SMTP and replacing its stored credentials.
- Administrator sign-in is rate limited per IP address and per account.
- Security headers on every response: Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
- Filter parsing rejects MongoDB operators outside a fixed allowlist, refuses field names containing $, and never searches or filters password fields.
- A workspace can no longer claim a subdomain the deployment uses for itself.
- Outbound destinations — databases, SMTP hosts, storage endpoints and webhooks — are checked against private address ranges before connecting.
- Connection strings and integration credentials are encrypted at rest and are never returned by any endpoint.