Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Docs / DCA Hardened Key-Value Store — for Valkey™ / Configuration

Configure DCA Hardened Key-Value Store — for Valkey™

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

Loopback only by default: Valkey answers on 127.0.0.1 and ::1, port 6379, and nothing but SSH listens beyond loopback. Opening it to your network takes two deliberate steps — a config change on the VM and a firewall rule — described under Network access.

Installed version

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)

First-boot credentials

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.

FileOwner / modeContents
/root/valkey-credentials.txtroot:root 0600Your copy: VALKEY_USER=default and VALKEY_PASSWORD=…
/etc/valkey/auth.confroot:valkey 0640The 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.

Log in

  1. Connect with 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.
  2. Load the password into 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          # PONG
  3. Without the password the server answers with a NOAUTH error; a wrong password gets WRONGPASS.

Password and ACL users

requirepass sets the password of Valkey's built-in default user — the only user on a fresh VM.

  • Change the password: edit requirepass in /etc/valkey/auth.conf, run sudo systemctl restart valkey, then update /root/valkey-credentials.txt (or your secret store) and your clients.
  • Give each application its own least-privilege user: add ACL user lines to /etc/valkey/auth.conf and restart — for example user app on >APP_PASSWORD ~app:* +@read +@write.
  • Runtime changes (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.
  • Protected mode stays on. Because a password is set, it does not block authenticated clients — the bind address and your firewall decide who can connect.

Network access

PortBound toDeployment package
6379 (Valkey)127.0.0.1 and ::1 — bind 127.0.0.1 -::1 in /etc/valkey/valkey.conftcp:6379 toggle, off by default
22 (SSH)all interfacesno rule — your VPC's own firewall rules apply

To serve clients on your VPC, do both halves:

  1. Add the VM's internal IP to 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 6379
  2. Open the port with the deployment package's firewall toggle: in its Networking section, tick "Allow TCP port 6379 traffic from the Internet" and enter your clients' CIDR ranges under "Source IP ranges for TCP port 6379 traffic". The toggle creates one VPC firewall rule, DEPLOYMENT-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-deployment
  3. From a client in an allowed range, connect with the password:
    VALKEYCLI_AUTH='…' valkey-cli -h 10.128.0.5 -p 6379 PING

Valkey 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.

Two more things decide who can reach an opened port on Google Cloud. If the VM sits on a 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.

Data and logs

WhatWhere
Data/var/lib/valkey — appendonlydir/ (AOF, appendfsync everysec) and dump.rdb (RDB, save 3600 1 300 100 60 10000)
Logsthe systemd journal — journalctl -u valkey -f (logfile "" with supervised systemd)
Configuration/etc/valkey/valkey.conf (root:valkey 0640) and /etc/valkey/auth.conf
Kernel settingvm.overcommit_memory = 1 in /etc/sysctl.d/90-valkey.conf, so background saves can fork under memory pressure
DiskThe 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.

What the shipped configuration sets

  • Persistence on: AOF every second plus RDB snapshots, both in /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.
  • The service runs as the valkey user with a systemd sandbox (ProtectSystem=strict, ProtectHome, PrivateTmp, NoNewPrivileges, an empty capability set); only /var/lib/valkey is writable.

Upgrades

  • Recommended: deploy the newest image version from the listing and move the data — stop 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.
  • In place: Valkey is not an apt package on this image, so neither 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.

Backup and restore

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.

Monitoring

  • Health: 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.
  • The deployment package disables the Cloud Logging and Monitoring agents in instance metadata (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.