TimeBase CE

Step 1 - Launch the VM

In the Azure portal, launch the SecureAnyCloud TimeBase Community Edition on Ubuntu 24.04 LTS offer from the Azure Marketplace. Pick a size, select or create a VNet, and allow inbound ports 22 (SSH) and 443 (HTTPS, the Web Admin) in the network security group. Standard_B2ms is a good starting point, and you can size up for higher throughput. Restrict port 22 to trusted source ranges.

You can also deploy from the Azure CLI. Replace the resource group, image URN, size and admin user to suit your environment.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:timebase-ce:default:latest
az vm create \
  --resource-group my-rg \
  --name timebase-ce \
  --image sac1647283583153:timebase-ce:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open ports 22 and 443 on the VM's network security group, and restrict port 22 to your own address range. Port 8011 (the native TimeBase protocol) is deliberately left closed and bound to loopback. Step 9 explains how to expose it to your own application when you need it.

Step 2 - Verify the services

Connect over SSH as azureuser and confirm that Docker, the TimeBase server and nginx are all active. The server publishes its native protocol and its Web Admin to loopback, and nginx serves the Web Admin over TLS on port 443.

systemctl is-active docker timebase nginx

sudo docker ps --format '{{.Names}} {{.Image}} {{.Status}}'

curl -s -o /dev/null -w 'nginx /healthz -> HTTP %{http_code}\n' http://127.0.0.1/healthz

Step 3 - Retrieve the per-VM admin password

Every VM generates its own TimeBase admin password on first boot and writes it, along with the Web Admin URL, to a root-only credentials file. Read the file with sudo.

sudo cat /root/timebase-ce-credentials.txt

The Web Admin is reachable over TLS and requires the credential. The native data port is bound to loopback and refuses connections from off the machine. You can confirm both with the following commands.

curl -sk -o /dev/null -w 'Web Admin unauthenticated -> HTTP %{http_code}\n' https://127.0.0.1/

IP=$(hostname -I | awk '{print $1}'); nc -z -w3 "$IP" 8011 && echo "8011 reachable off box" || echo "8011 refused off box (loopback only)"

Sign in to the Web Admin as user admin with the TIMEBASE_ADMIN_PASSWORD from this file. The same credential authenticates the tickdb shell and any client that connects over the native protocol.

Step 4 - Sign in to the Web Admin

Go to https://<vm-public-ip>/ in a browser. The certificate is a per-VM self-signed certificate, so your browser warns you on the first visit. Accept the warning to continue, or front the VM with your own domain and certificate (see Step 9). When prompted, enter the username admin and the password from Step 3. The QuantServer monitoring home shows the running server version and its administration tools.

Step 5 - View live connections

Open the TimeBase monitor and select Connections to see every client currently connected to the server, with its client id, application, connection time and remote address. The example below shows several tickdb shell sessions connected at once.

Step 6 - Inspect cursors and loaders

Cursors lists the open read cursors, so you can see exactly which streams are being queried in real time. Loaders lists the open writers, so you can see which streams are being ingested into. The examples below show read cursors and a loader both working against the bars stream that Step 7 creates.

Step 7 - Write and query time series data

The image includes a timebase-shell command that runs the version-matched tickdb shell inside a container, connected to the server over loopback. This example uses the built-in sample producer to create a bars stream and load time-series bar messages, then reads them straight back with a select. Retrieve the password first, then run the shell.

PW=$(sudo grep '^TIMEBASE_ADMIN_PASSWORD=' /root/timebase-ce-credentials.txt | cut -d= -f2-) sudo timebase-shell <<EOF set db dxtick://admin:$PW@localhost:8011 open generate bars set max 6 set stream bars select exit EOF

The output shows the generated SimpleBarMessage rows for several symbols, each with an open, high, low, close and volume, printed straight back from the stream you just wrote.

To define your own stream and write your own messages, use the tickdb shell (mkstream, send) or one of the TimeBase client libraries (Java, .NET, Python and C++) over the native protocol. Create a dedicated, least-privilege user for each application rather than sharing the admin credential.

Step 8 - Confirm there are no default credentials

TimeBase Community Edition ships with authentication disabled by default. The SecureAnyCloud image turns authentication on and sets a unique per-VM admin password on first boot. The server will not start until that per-VM secret is in place. To confirm that there is no known or default login, run the built-in round-trip check. It confirms that the per-VM admin authenticates and reads data, while common default logins are rejected.

sudo bash /usr/local/sbin/timebase-ce-cred-roundtrip.sh

Step 9 - Expose the native protocol to your application

By default, the native TimeBase protocol on port 8011 is published to loopback only, so client libraries on other machines cannot reach it. When you are ready to connect your own application over the network, edit the service so that the server port is published on the private network interface. Then open port 8011 in the network security group, scoped to your application's subnet only.

sudo sed -i 's/-p 127.0.0.1:8011:8011/-p 8011:8011/' /etc/systemd/system/timebase.service
sudo systemctl daemon-reload && sudo systemctl restart timebase

Authentication stays enabled, so even once the port is open, clients must present the per-VM admin credential or a dedicated user that you create. Keep the security group rule as tight as possible, and prefer a private VNet over public exposure.

Where your data lives

TimeBase stores all of its streams and message data at /var/lib/timebase/home on the OS disk, bind-mounted into the server container as /timebase-home. The data persists across container restarts and VM reboots. Inspect it with the following command.

sudo du -sh /var/lib/timebase/home

For backups, stop the service and take a file-level backup of that directory, or use the TimeBase tooling to export stream data.

Security notes

• Authentication is enabled, and the admin password is unique to every VM. Keep /root/timebase-ce-credentials.txt protected, and create dedicated per-application users rather than sharing the admin credential.
• The Web Admin is served over TLS with a per-VM self-signed certificate. For anything beyond a trusted network, front it with your own domain and a certificate from Azure Application Gateway, an nginx or Caddy reverse proxy, or a managed load balancer.
• Only ports 22 (SSH) and 443 (Web Admin over TLS) are exposed by default. The native protocol on 8011 is bound to loopback until you deliberately open it (Step 9). Restrict every open port to trusted source ranges in the network security group.
• The base OS is fully patched at build time and keeps unattended security updates enabled for ongoing protection.

Support

This image is built and maintained by SecureAnyCloud with 24/7 support. TimeBase Community Edition is free and open-source software licensed under the Apache License 2.0 and governed by the Fintech Open Source Foundation (FINOS). This image is provided by SecureAnyCloud and is not affiliated with or endorsed by FINOS, EPAM Systems or the TimeBase project.

Deploy on Azure

Launch TimeBase Community Edition on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com