Home / Docs / DCA Hardened Key-Value Store — for Valkey™ / Configuration
Valkey 9.1 on loopback with protected mode on and a password generated on each VM's first boot — none ships in the image.
On this page: Installed version · First-boot credentials · Log in · Password and ACL users · Network access · Data and logs · What the shipped configuration sets · Upgrades · Backup and restore
Valkey 9.1.2 — the official prebuilt Ubuntu 24.04 (noble) x86-64 binaries from download.valkey.io, sha256-pinned and checked against the release's own .sha256 file when the image was built. They live in /opt/valkey/bin; valkey-server, valkey-cli, valkey-benchmark, valkey-check-rdb, valkey-check-aof and valkey-sentinel are linked into /usr/local/bin. Base OS: Ubuntu 24.04 LTS. Image built 2026-10-07; every build is gated on zero fixable HIGH or CRITICAL vulnerability findings.
valkey-server --version
valkey-cli INFO server | grep valkey_version # needs VALKEYCLI_AUTH (below)There is no default password. On this VM's first boot, valkey-firstboot.service generates a 32-character password before the server first starts and writes it to two files; valkey-verify-firstboot.service then proves against the running server that the password works and that no password, or a wrong one, is refused.
| File | Owner / mode | Contents |
|---|---|---|
/root/valkey-credentials.txt | root:root 0600 | Your copy: VALKEY_USER=default and VALKEY_PASSWORD=… |
/etc/valkey/auth.conf | root:valkey 0640 | The server's copy: requirepass …, included by valkey.conf |
The password is generated once. /etc/valkey/auth.conf decides: while it exists no new password is minted, so you can move /root/valkey-credentials.txt into your secret store without getting a new password on the next boot.
gcloud compute ssh INSTANCE_NAME --zone ZONE --tunnel-through-iap. The deployment package enables OS Login, so IAM decides who can SSH in; reading the credential files needs sudo, which OS Login grants to principals with the OS Admin Login role (roles/compute.osAdminLogin). IAP TCP forwarding needs a firewall rule that allows 35.235.240.0/20 to tcp:22 on the VM's network — the deployment package does not create one.valkey-cli's environment variable, so it stays out of the process list, and ping:export VALKEYCLI_AUTH="$(sudo sed -n 's/^VALKEY_PASSWORD=//p' /root/valkey-credentials.txt)"
valkey-cli PING # PONGNOAUTH error; a wrong password gets WRONGPASS.requirepass sets the password of Valkey's built-in default user — the only user on a fresh VM.
requirepass in /etc/valkey/auth.conf, run sudo systemctl restart valkey, then update /root/valkey-credentials.txt (or your secret store) and your clients.user lines to /etc/valkey/auth.conf and restart — for example user app on >APP_PASSWORD ~app:* +@read +@write.CONFIG SET requirepass …, ACL SETUSER …) last only until the next restart. No aclfile is configured, and /etc/valkey is read-only to the service (ProtectSystem=strict; only /var/lib/valkey is writable), so ACL SAVE and CONFIG REWRITE cannot persist them. Put them in the files.bind address and your firewall decide who can connect.| Port | Bound to | Deployment package |
|---|---|---|
| 6379 (Valkey) | 127.0.0.1 and ::1 — bind 127.0.0.1 -::1 in /etc/valkey/valkey.conf | tcp:6379 toggle, off by default |
| 22 (SSH) | all interfaces | no rule — your VPC's own firewall rules apply |
To serve clients on your VPC, do both halves:
bind in /etc/valkey/valkey.conf — keep the loopback entries so valkey-cli on the VM still works — and restart:# /etc/valkey/valkey.conf (10.128.0.5 = your VM's internal IP)
bind 127.0.0.1 -::1 10.128.0.5
sudo systemctl restart valkey
ss -tln | grep 6379DEPLOYMENT-tcp-6379, allowing tcp:6379 from those ranges to VMs tagged DEPLOYMENT-deployment (DEPLOYMENT is your deployment name; the VM is DEPLOYMENT-vm). Use the narrowest ranges that work — 0.0.0.0/0, which the field shows only as a format example, would publish the port through the VM's external IP. Already deployed without the toggle? Create the same rule yourself:gcloud compute firewall-rules create DEPLOYMENT-tcp-6379 \
--network NETWORK --direction INGRESS --allow tcp:6379 \
--source-ranges 10.10.0.0/24 --target-tags DEPLOYMENT-deploymentVALKEYCLI_AUTH='…' valkey-cli -h 10.128.0.5 -p 6379 PINGValkey speaks plain TCP on 6379 as shipped — no TLS listener is configured. Keep it on private addresses, and carry traffic that leaves your VPC over a VPN or tunnel.
default network that still has its pre-created default-allow-internal rule (all ports from 10.128.0.0/9), every VM in that network can connect as soon as the service listens on the internal IP — toggle or not. And the deployment package gives the VM an ephemeral external IP by default (its External IP field), so a rule open to 0.0.0.0/0 would put the service on the internet. Put authentication in place first, then open the narrowest range that works.| What | Where |
|---|---|
| Data | /var/lib/valkey — appendonlydir/ (AOF, appendfsync everysec) and dump.rdb (RDB, save 3600 1 300 100 60 10000) |
| Logs | the systemd journal — journalctl -u valkey -f (logfile "" with supervised systemd) |
| Configuration | /etc/valkey/valkey.conf (root:valkey 0640) and /etc/valkey/auth.conf |
| Kernel setting | vm.overcommit_memory = 1 in /etc/sysctl.d/90-valkey.conf, so background saves can fork under memory pressure |
| Disk | The deployment package creates one boot disk (default 50 GB, balanced persistent disk) and no separate data disk, so the data above lives on the boot disk — size it for your data, or mount a persistent disk at the data path. |
/var/lib/valkey — data survives a restart and a reboot (verified on booted VMs).enable-debug-command no, enable-module-command no and enable-protected-configs no: no DEBUG, no runtime module loading, and protected settings such as dir cannot be changed with CONFIG SET.valkey user with a systemd sandbox (ProtectSystem=strict, ProtectHome, PrivateTmp, NoNewPrivileges, an empty capability set); only /var/lib/valkey is writable.valkey on both VMs, copy the contents of /var/lib/valkey (appendonlydir/ and dump.rdb) to the new VM, run sudo chown -R valkey:valkey /var/lib/valkey, and start valkey. The new VM keeps its own password.apt nor unattended-upgrades (enabled, for Ubuntu's own updates) ever changes it. To move to a newer release, download its noble-x86_64 tarball and .sha256 from download.valkey.io, check the hash, replace the binaries in /opt/valkey/bin, and sudo systemctl restart valkey. Read the Valkey release notes first.Snapshot the boot disk, or copy the whole /var/lib/valkey directory (appendonlydir/ and dump.rdb) with valkey stopped. Restore the same way: stop valkey, put both back from the same backup, sudo chown -R valkey:valkey /var/lib/valkey, and start it.
VALKEYCLI_AUTH="$(sudo sed -n 's/^VALKEY_PASSWORD=//p' /root/valkey-credentials.txt)" valkey-cli PING → PONG — wire this into an uptime check or your monitoring agent.google-logging-enable=0, google-monitoring-enable=0), and the image pre-installs no monitoring agent. Install the Google Cloud Ops Agent if you want logs and metrics in Cloud Logging and Cloud Monitoring; nothing phones home by default.More: install · troubleshooting · security notes · support card. Questions: support@dcassociatesgroup.com — first response within 1 business day.
Valkey™ names the open-source software this image packages. Derek Coleman & Associates Inc is not affiliated with or endorsed by the Valkey project.