How Cache works, and what to use it for

Data lives in memory, so it answers very fast. It’s written to disk every second, and you connect the same way as a database.

Project VPC (private network)Your appContainer in the Project1name.internal :6379CacheThailandHosting Cache · ValkeyTo disk every second (AOF)Your computeror outside systems2TLS + SNI + IP3Back up4Restore by ticketBackupScheduled + on demandBacked up on your schedule · keeps the copies you pickBack up any time
A cache uses the same network setup as a database. The differences: the data is in RAM, and restoring needs our team’s help.

Step by step, following the numbers

  1. Apps in the same Project connect with server-name.internal on port 6379. If you link the cache to a container, a redis:// DATABASE_URL is set for you.
  2. To connect from outside, turn on the public endpoint, add allowed IPs, and connect over TLS with SNI (rediss://).
  3. Data is in RAM and written to disk every second, so it survives a restart. The data file is backed up on the schedule you set.
  4. To restore, open a ticket and our team restores it from a backup for you.

What a cache is good for

  • Sessions of signed-in users, so every instance of your app sees the same data.
  • Caching results you read from the database often or that take long to work out, so pages load faster.
  • Job queues and counters, such as sending email in the background or limiting how often an API can be called.

Don’t use a cache as your main data store. If the data grows past the RAM you chose, nothing more can be written. Keep important data in a Managed Database, and set keys to expire.

Still stuck? Let our team help

Open a ticket from the Console. Tell us the site or service, what you did and the message on screen. Our reply comes back in the same ticket, so everything stays in one place.

Open a ticket All guides