SYstem VERification in a single self-contained binary: generate a spec from a running host, validate against it, or serve it as a health endpoint
A build that succeeded is not the same as a build that is correct. The playbook exited zero, the image published, the container started, and none of that tells you whether the service is actually listening on the port you think, whether the package that got installed is the version you pinned, or whether a later change quietly undid the first one.
Syver is a YAML based alternative to serverspec for validating a server's configuration. You describe the state a host is supposed to be in, and Syver checks it. The spec is a plain YAML file that lives in the repository next to the code that builds the host, so the definition of correct is reviewed, versioned, and diffable like everything else.
It covers package, file, addr, port, service, user, group, command, dns, process, kernel-param, mount, interface and http, plus registry on Windows, with imports so a large estate can share common blocks rather than copying them. It ships as one self-contained binary under 20MB with no runtime to install, which is what makes it practical to drop into a container build or a golden image pipeline.
The same spec file serves all three, which is the point: what you assert at build time is what you keep asserting in production, rather than two separate sets of checks that drift apart.
syver autoadd sshd reads the current state of the host and writes the assertions for you. Starting from a machine that already works is far quicker than writing a spec from scratch, and it catches the details you would not have thought to assert.
syver validate runs the suite and exits non-zero on failure, which is all a CI job needs. Small and medium suites finish near instantaneously, so it is cheap enough to run on every build rather than nightly.
syver serve exposes the same spec as an HTTP health endpoint. A Kubernetes readiness probe or a load balancer check can then ask the question the spec already answers instead of settling for "the process is up".
There is also syver render for templated specs with variable injection, syver add for building a spec up by hand, and dsyver, dcsyver and ksyver wrappers for Docker, Docker Compose and Kubernetes.
Syver is the renamed continuation of our krameff/goss fork, which is now archived. The original is goss-org/goss by @aelsabbahy; all of that work remains under Apache 2.0 and full credit goes to the original author for a genuinely solid foundation.
Syver has since diverged. The work is driven by what clients actually need rather than by tracking upstream, so the two projects will keep differing and release-for-release parity is not a goal. The file format is a separate matter, and it is held stable on purpose. The product renamed; your specs did not.
gossfile: is still the canonical key and still what gets written out. goss.yaml and goss.yml are still probed, alongside the syver names. Syntax, resource types and matchers are unchanged, so there is no spec rewrite to schedule.
All sixteen GOSS_* variables are still honoured, permanently rather than as a deprecation. SYVER_* takes priority where both are set, and an exported but empty SYVER_* is treated as unset so it never shadows a real GOSS_*.
The JUnit suite name is still goss, the Nagios prefixes are still GOSS OK and GOSS CRITICAL, and goss_tests_* Prometheus metrics are still emitted with the Syver names alongside them rather than instead of them. Whatever reads your output does not need touching.
dgoss, dcgoss and kgoss still ship and still work as shims, and the goss-<os>-<arch> release archive is still published. Both are kept for one major version rather than indefinitely, so they are a migration window, not a promise.
The binary is syver, so anything that shells out to goss by name needs one symlink. The outbound User-Agent on http checks, the checksum filename, and the container image all carry the new name too. Only relevant if you assert on them.
If you import this as a Go library rather than running the CLI, the module path moved and the Resource interface and entry points now take a context.Context first. That is what makes interrupt handling work, and it is the one break that is not just a rename.
Three behaviours differ from upstream. None of them change what a spec file means, and a run that is allowed to finish produces identical results either way. Each came out of something going wrong in front of a client.
goss mints a fresh context inside each check, so interrupting a run leaves any command it had already started to finish on its own, orphaned. Syver threads the signal handler's context all the way down to exec, so the child dies with the parent.
syver serve also shuts down in an orderly way on SIGTERM rather than being killed mid-request, and a second signal always terminates the process outright, so nothing can become unkillable.
A typo in a top-level key used to drop the entire block under it and validate the rest of the file as though it had never been written, still exiting zero. A spec that silently skips a section you believed was being checked is worse than one that fails.
Syver now logs a [WARN] naming the file, the line, and a suggested fix where the key is close to a real one. Worth running over a large spec collection: a file that validated clean under goss may turn out to have been ignoring a block the whole time.
/metrics served an empty registry under goss, which is a quiet way to have monitoring that reports nothing and looks healthy doing it. It now serves the real metrics.
CentOS 7 has also been dropped from the test matrix. It is end of life, and its systemd never activates services inside a container, so the results it produced were not telling us anything true.
Hardening and validation answer different questions. A CIS or STIG role applies a control; it does not, by itself, tell you six months later that the control is still in place. Configuration drifts, an emergency change gets made at 2am, a base image is rebuilt from a different source, and the evidence that anything is still compliant is a playbook run from last quarter.
Validation closes that gap. A spec is an assertion about the state of a host that can be run on demand, on a schedule, or as a health check, and its output is a JUnit or JSON artefact an auditor can actually read. It is the difference between "we applied the benchmark" and "here is the host, checked this morning, and here is what it said".
That is how we use Syver in practice: the hardening work we do with Ansible-Lockdown applies the controls, and a validation spec proves they held. Neither is much use without the other.
This page is the overview. The full reference lives at syver.readthedocs.io, built from the same repository as the code, so it changes when the tool does. The pages most people want first:
Derive a first set of tests from a running host with autoadd, then validate against them.
Release binaries, the container image, and platform notes for Windows and macOS.
Every resource type, its attributes and matchers, and how imports and templates fit together.
Each subcommand and flag, with the SYVER_* and GOSS_* environment variables that set them.
Testing images and running pods with the dsyver, dcsyver and ksyver wrappers.
What to check when moving an existing goss setup across, step by step.
Short, silent screen recordings of Syver doing real work on a real host and in real containers.
Syver's autoadd command reads the running sshd service on a host and writes a spec for its process, service and user into syver.yaml. The spec is then edited to expect sshd to be stopped, standing in for drift between what was declared and what is running, and syver validate reports the two failed checks and skips the two that depended on them.
The nginx:alpine image is pulled and syver.yaml expects the nginx package to be installed, the nginx user to exist, nginx -v to exit 0 and /etc/nginx/nginx.conf to exist. dsyver run starts a throwaway container from the image, runs the four checks inside it, then stops and deletes the container, and all four pass. The spec is then extended to expect /etc/nginx/conf.d/tls.conf, a file the image does not have, and the rerun reports that check as failed and exits with status 1.
A compose.yaml defines a web service from the nginx:alpine image, and syver.yaml expects the nginx process to be running, TCP port 80 to be listening and /etc/nginx/nginx.conf to exist. dcsyver run web starts the service, runs the three checks against it and stops it, and all three pass. Expecting /etc/nginx/conf.d/tls.conf as well, a file the image does not have, makes the next run fail that check and exit with status 1.
Syver is the renamed continuation of the krameff/goss fork of goss-org/goss, which is now archived. It began as a fork and has since diverged: the work is driven by client requirements rather than by tracking upstream, so release-for-release parity with goss-org/goss is not a goal. The spec file format is a separate matter and is deliberately held stable.
No. The product renamed, the file format did not. The gossfile: key is still canonical, goss.yaml and goss.yml are still probed, all sixteen GOSS_* environment variables are still honoured, the --gossfile and -g flags still work, and gossfile syntax, resource types and matchers are unchanged.
Almost everything that breaks is something that referenced the product by name: the binary is syver rather than goss, the outbound User-Agent on http checks is syver/<version>, the checksum file is syver_<version>_SHA256SUMS, and the container image is ghcr.io/krameff/syver. If you import the project as a Go library rather than using the CLI, the module path changed and the Resource interface and library entry points now take a context.Context first. Anything that shells out to goss by name can be fixed with a symlink.
Linux has full support and is tested against AlmaLinux 10, Alpine 3, Arch, Debian Bullseye, Ubuntu Jammy and Rocky Linux 9. Windows and macOS support is alpha, with some resources such as port only partly implemented outside Linux. The registry resource is Windows only.
rspecish is the default, alongside documentation, json, structured, tap, junit, nagios, prometheus and silent. The JUnit suite name and the Nagios GOSS OK and GOSS CRITICAL prefixes are deliberately unchanged so existing CI parsers keep working, and goss_tests_* Prometheus metrics are still emitted with syver_tests_* alongside them rather than instead of them.
Yes to both. Syver is free and open source under the Apache 2.0 licence, and always will be. We also offer paid support and maintenance arrangements for it, as we do for ssh_key_rotation, so there is someone to call when an upgrade needs planning or a spec does not hold up against your estate. Talk to us about support and we will scope it around what you run. Security issues should be reported privately to security@krameff.com rather than as a public issue.
Writing a spec for one host is an afternoon. Deciding what is worth asserting across a mixed estate, wiring it into CI and health checks, and turning the output into evidence someone will accept at audit is the harder half. That is the part we help with, and we offer ongoing support once it is in place.
Talk to Us