Skip to content

Syver - Quick and Easy server validation

Syver - by Krameff Solutions Ltd

Note: For testing containers see the dsyver wrapper. There are also wrapper scripts for Kubernetes (ksyver) and Docker Compose (dcsyver), and for Docker Sandboxes, the sbx microVMs coding agents run in (sbxsyver). The goss-named dgoss, kgoss and dcgoss still ship alongside them and work unchanged.

Note: For some Docker/Kubernetes healthcheck, health endpoint, and container ordering examples, see the Docker/Kubernetes simplified health checks blog post.

Introduction

What is Syver?

Syver is a YAML based serverspec alternative tool for validating a server's configuration. It eases the process of writing tests by allowing the user to generate tests from the current system state. Once the test suite is written it can be run once, retried until it passes or times out, or served as a health endpoint.

See it running: the demo videos show autoadd catching drift, dsyver testing a Docker image and dcsyver checking a Docker Compose service.

Syver is maintained by Krameff Solutions.

Why use Syver?

  • Syver is EASY!
  • Syver is FAST! - small-medium test suites are near instantaneous
  • Syver is SMALL! - <20MB single self-contained binary

Coming from goss?

Syver is the renamed continuation of the krameff/goss fork. Your gossfiles do not need to change. gossfile:, goss.yaml, GOSS_* env vars, the dgoss/dcgoss/kgoss wrappers and the -g flag all keep working.

See goss vs Syver for the full side-by-side comparison and the upgrade steps, including the breaking changes, all of which are names rather than spec syntax.

Installation

Note: For macOS and Windows, see platform support.

Build from source or install release binaries — see installation.

This installs syver, the dsyver container wrapper, and dgoss as a compatibility shim.

Supported resources

  • package - add new package
  • file - add new file
  • addr - add new remote address:port - ex: google.com:80
  • port - add new listening [protocol]:port - ex: 80 or udp:123
  • service - add new service
  • user - add new user
  • group - add new group
  • command - add new command
  • dns - add new dns
  • process - add new process name
  • registry - add new Windows registry key or value (Windows only)
  • kernel-param - add new kernel-param
  • mount - add new mount
  • interface - add new network interface
  • http - add new network http url with proxy support
  • syver (alias: goss) - add new syver file, it will be imported from this one
  • matching - test for matches in supplied content

Supported output formats

  • rspecish - (default) Similar to rspec output
  • documentation - Verbose test results
  • json - JSON, detailed test result
  • structured - JSON like json, plus a summary object and a human-readable summary-line on every result
  • tap - TAP style
  • junit - JUnit style
  • nagios - Nagios/Sensu compatible output /w exit code 2 for failures.
  • prometheus - Prometheus compatible output.
  • silent - No output. Avoids exposing system information (e.g. when serving tests as a healthcheck endpoint).

Community Contributions

These are third-party integrations written for upstream goss. They are listed because they still work, but each one invokes a binary named goss, and install.sh installs syver, dsyver and dgoss, but no goss. To use any of them, put a goss on your PATH pointing at syver:

sudo ln -s "$(command -v syver)" /usr/local/bin/goss

The gossfiles these tools generate and consume need no changes; only the binary name differs. None of them are maintained by this project.

  • goss-ansible - Ansible module for Goss.
  • degoss - Ansible role for installing, running, and removing Goss in a single go.
  • ansible-goss-install - Ansible role for installing Goss (option for install as user or root)
  • kitchen-goss - A test-kitchen verifier plugin for Goss.
  • goss-fpm-files - Might be useful for building goss system packages.
  • packer-provisioner-goss - A packer plugin to run Goss as a provision step.
  • gossboss - Collect and view aggregated Goss test results from multiple remote Goss servers.

Limitations

syver works well on Linux, but support on Windows & macOS is alpha. See platform support.

The following tests have limitations.

Package:

  • rpm
  • deb
  • Alpine apk
  • pacman

Service:

  • systemd
  • sysV init
  • OpenRC init
  • Upstart
  • Windows Service Control Manager (alpha, with six Windows-only attributes -- see windows)

Port:

  • Port state is read from /proc/net/{tcp,udp,tcp6,udp6} on Linux, where it is fully supported. It is not implemented on macOS or Windows: measured on Windows Server 2025, every assertion returns "not implemented yet". See platform support, which is the authoritative per-resource matrix.
  • On Linux, if one of those files exists but contains a line syver can't parse (an unexpected IP/port/uid encoding, typically from a non-standard procfs, e.g. inside certain containers or network namespaces), the affected port resource now fails with an explicit Error: block in the output instead of silently reporting the port as not listening. To investigate: note which protocol failed from the resource id (tcp, tcp6, udp, udp6), then inspect the corresponding file directly, e.g. cat /proc/net/tcp6, and compare its columns against a working host. A missing or unreadable file is not an error case -- it's treated as "no ports" for that protocol.

Documentation

⌂ 换网址