Two-layer caching
Redis & Varnish
Redis caches inside your application; Varnish caches in front of your web server. Complementary, not competing. Many servers run both for maximum performance.
2
Caching layers
5
Eviction policies
1
Click VCL edit
0
Silent drift
Two complementary caching layers
Redis sits behind your application and caches whatever your code stores. Varnish sits in front of your web server and caches whole HTTP responses. Many servers run both for maximum performance.
Redis
Application-level caching — queries, sessions, computed values
Varnish
HTTP response caching — whole pages served without hitting your app
VCL Editing
Fetch running VCL, upload custom .vcl files, compile errors shown
Drift Detection
Live config read from machine, compared to saved panel config
Redis — application-level caching
Redis sits behind your application and caches whatever your code stores — queries, sessions, computed values. The single most consequential setting is the eviction policy, and the panel explains which to choose.
- noeviction — rejects writes when full (correct for queues/sessions)
- LRU/LFU — evicts old entries (correct for a pure cache)
- Persistence toggle — on for sessions/queues, off for pure cache (faster)
- Max Memory ceiling configurable
- Connection info exposed for app-side wiring
Varnish — HTTP response caching
Varnish sits in front of your web server and caches whole HTTP responses. No app changes needed. The Default Grace setting serves slightly-stale content during an app outage instead of showing errors.
- Full port architecture exposed — public Listen Port to Varnish to Backend Port
- Server Type selector (Nginx/Apache) for correct configuration
- Cache Size, Default TTL, and Default Grace configurable
- Connect Timeout and First Byte Timeout tuning
- Purge ACL — CIDR-restricted, controls who can trigger cache purge
Port Architecture
In-panel VCL editing
Direct VCL editing in the panel — fetch the currently-running VCL, upload a custom .vcl file to replace the default. This is where real caching logic is expressed: cookie handling, path exclusions, device variation.
- Fetch currently-running VCL from the server
- Upload custom .vcl files
- Per-source logs: NCSA access, backend errors, systemd/journalctl
- VCL compile failure logs shown directly
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
if (req.url ~ "/api/") {
return (pass);
}
}
$
Live configuration drift detection
Live Configuration on Server reads the actual running config from the machine — distinct from the last-saved panel config. This surfaces drift from manual edits before it causes an outage.
- Reads actual running Redis config from the machine
- Compares to last-saved panel config
- Surfaces drift from manual SSH edits
- A specific, callable-out differentiator across the platform
Panel Config
Live Config
Many servers run both
Redis and Varnish are complementary, not competing. Redis handles application-level caching while Varnish handles HTTP-level caching. Running both gives you two layers of speed — your app serves fewer requests, and the requests it does serve are faster.
Redis: queries, sessions, computed values cached in memory
Varnish: full HTTP responses served without touching your app
Grace periods keep content served during backend outages
Client
Browser request
Varnish
HTTP cache layer
Nginx
Web server
App
Your application
Redis
App cache layer
Everything around your cache
Pair caching with the tools that keep your applications fast, secure, and resilient.
SharkCluster supports two complementary caching layers: Redis for application-level caching (queries, sessions, computed values) and Varnish for full HTTP response caching in front of your web server.
Yes, SharkCluster provides in-panel VCL editing. You can fetch the currently-running VCL and upload a custom .vcl file to replace the default.
Live Configuration on Server reads the actual running Redis or Varnish config from the machine and compares it to the last-saved panel config, surfacing any drift from manual edits.
Ready to take control
of your hosting?
Deploy servers, run self-hosted business apps, and keep your data on your own VPS — with a dedicated DevOps manager by your side.