SurrealDB, A Record Written And Read Back
SurrealDB (SHA-256 pinned) on EL 10 from the upstream release, as a hardened systemd service on loopback; the live test sees an anonymous query and a wrong password refused, defines a namespace and a database, creates a record and reads it back, and checks the version endpoint; the root credentials live in the unit environment. Original role, live-tested on Rocky Linux 10.
Verification
Live-testedReally deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.
Conformance
- Static validation (yamllint · ansible-lint)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live-tested - applied, verified, destroyed
Last verified 2026-09-26 · podman 4.9.3 · ansible 2.21.4 · how we verify
Cite it in your README
badge · attributionPaste this beside the module in the repository that uses it. The badge is rendered from this artifact's verification record, so it reads live-tested because the record says so, and the link lands on this page.
[](https://www.iac-bazaar.com/catalog/ansible-surrealdb?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
Ansible role 1.0.0, live-tested on IaC Bazaar: [SurrealDB, A Record Written And Read Back](https://www.iac-bazaar.com/catalog/ansible-surrealdb?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
```yaml
# SurrealDB, A Record Written And Read Back: https://www.iac-bazaar.com/catalog/ansible-surrealdb (download from your IaC Bazaar account)
```Preview:
Documentation
surrealdb
SurrealDB from the upstream release (SHA-256 pinned per architecture), as a hardened system service on loopback with its RocksDB store under /var/lib/surrealdb and its root credentials in the unit's environment rather than the command line. Original role for EL 10, live-tested with podman on Rocky Linux 10.
No package, and no checksum file to speak of. EL 10 carries no
surrealdb, and SurrealDB publishes the release with nothing beside it. This
role pins the SHA-256 per architecture beside the version, has Ansible's
get_url refuse the asset unless it matches, and installs the binaries
as root's in /usr/local/bin. A new release is a new pair, on purpose.
A service account, a hardened unit, a loopback listener. surrealdb
is a system user with no shell that owns the data directory and nothing
else; the unit runs with NoNewPrivileges, PrivateTmp, ProtectHome and
ProtectSystem=strict. The listener is 127.0.0.1:8000 by default,
for a proxy that authenticates or a client on the same host; the live test
reads the listening sockets and expects loopback only.
Proven by a record that went in and came back. The live test sees an
anonymous query and a wrong password refused, defines a namespace at root
level and a database inside it (the DEFINE runs one level above the thing
it defines, so those two calls carry different headers), creates a record,
reads it back, and checks /version names the release this role
installed.
The root user is the bootstrap, not the application's login. It comes
from SURREAL_USER and SURREAL_PASS in the unit's environment, so it
never appears in ps; define namespace and database users for anything
that connects afterwards. The store is a positional argument, so switching
to memory for a cache is a one-line change in surrealdb_store.
License
Commercial - IaC Bazaar EULA. (c) IaC Bazaar.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Variables
- Test
Related modules
ansible-clickhouse
ClickHouse on EL 10 from the upstream LTS release (sha512-verified), as a hardened systemd service on loopback with the default user behind a password; the live test creates a MergeTree table, inserts a row and selects it back over HTTP; a query without credentials is refused. Original role, live-tested on Rocky Linux 10.
ansible-dragonfly
Dragonfly on EL 10 from the vendor's release, pinned by a SHA-256 the role carries (the vendor publishes no checksum file), as a hardened systemd service on loopback behind a password kept in a flagfile; the live test speaks RESP itself: an unauthenticated PING and a wrong password are refused, AUTH + SET + GET round-trip. Original role, live-tested on Rocky Linux 10.
ansible-influxdb3
InfluxDB 3 Core on EL 10 from the vendor's release (checksum-verified), as a hardened systemd service on loopback with file object storage; the binary runs from its release directory (it links the Python it ships); the live test writes a point in line protocol and reads it back with SQL. Original role, live-tested on Rocky Linux 10.
ansible-mariadb-server
MariaDB bound to loopback (the package listens everywhere), with the mariadb-secure-installation steps applied by the role: anonymous users, the test database and remote root gone, LOAD DATA LOCAL off, reverse DNS off. Provisions an application database and a user that can see nothing else. Original role, live-tested on Rocky Linux 10.
ansible-meilisearch
Meilisearch on EL 10 from the vendor's release, pinned by a SHA-256 the role carries (the vendor publishes no checksum file), as a hardened systemd service on loopback in production mode behind a master key; the live test creates an index and documents, waits for the indexing task, searches and finds the one match, and sees a keyless request refused. Original role, live-tested on Rocky Linux 10.
ansible-opensearch
OpenSearch 3 (sha512-verified min distribution, bundled JDK), one node on EL 10 from the upstream release, as a hardened systemd service on loopback; the live test reads the root document, indexes one document with a refresh, finds it by a search, deletes the index and checks the keystore belongs to the service; the release tree stays read-only. Original role, live-tested on Rocky Linux 10.