How your users' sessions are stored has a direct impact on what your hosting can look like. A single web server can keep session files on its own disk and never think about it; the moment you put two web servers behind a load balancer, those file-based sessions stop working unless you switch to a shared store. ActiveManage supports four session modes and the right one for you depends entirely on your deployment shape.
The setting that drives this is PHP Session Mode under Site Settings → Session. You'll typically pick a mode once at install time and never touch it again, but if your infrastructure changes — for example you migrate from a single Apache box to an AWS Beanstalk auto-scaling group — you'll come back to revisit it.
files
The standard PHP session mode and the platform's default. Session data is written to files in a temporary folder on the web server itself (typically /tmp or the directory set in session.save_path). It needs zero additional infrastructure, runs everywhere PHP runs, and is the simplest mode to debug because you can literally cat a session file.
The downside is that sessions are pinned to one web server. If your hosting later puts a load balancer in front of multiple servers, a user who logs in on server A and is then routed to server B will look unauthenticated, because server B can't see server A's session files. Some load balancers can be configured for sticky sessions to work around this, but it's a fragile arrangement.
Use files mode when: you're running a single web server, you're in development, or you're confident you'll never need to scale out horizontally.
redis
Sessions are stored in a Redis database — an in-memory key-value store known for very low-latency reads and writes. Redis is the de-facto choice for load-balanced PHP deployments because every web server reads sessions from the same Redis instance, so requests can be served by any server and find the right session.
You'll need a Redis server reachable from each web server. Common patterns: a dedicated EC2 instance running Redis, an AWS ElastiCache for Redis cluster, or a managed Redis service like Redis Cloud or Upstash. Configure the hostname and port via the Session Server Hostname and Session Server Port Site Settings.
Use Redis mode when: you're running multiple web servers behind a load balancer, you want fast session reads, and you have (or can spin up) a Redis instance.
memcached
Sessions are stored in a Memcached system. Functionally similar to Redis — multi-server-friendly, fast — but with a simpler feature set (no native persistence, simpler data types). The choice between Redis and Memcached usually comes down to whatever's already running in your infrastructure rather than any meaningful capability difference for session storage specifically.
Like Redis, you'll point ActiveManage at a Memcached host via the same Session Server Hostname and Session Server Port settings. AWS ElastiCache supports both, so on AWS the decision often comes down to whether you also need Redis's broader feature set for other parts of your stack.
dynamodb
Sessions are stored in an AWS DynamoDB table. This is the right pick for serverless or auto-scaling deployments — DynamoDB is fully managed, scales automatically, and doesn't require you to size and maintain a Redis or Memcached instance.
Configure the endpoint via $AM_awsDDBendpoint and the table name via $AM_awsDDBsessionTBL in your config. The AWS credentials configured for S3 and SNS are reused. DynamoDB read/write costs are typically negligible for session traffic — each request is a single small read and (occasionally) a small write.
Use DynamoDB mode when: you're deploying to AWS and want zero session-server management, or you're running in a serverless environment where keeping a long-running Redis/Memcached process around is awkward.
Choosing the right mode for your deployment
To summarise the typical decision matrix:
- Single server, internal tools, dev/staging: files.
- Load-balanced production on your own infrastructure: Redis (or Memcached if it's already there).
- AWS production with autoscaling: DynamoDB, or Redis via ElastiCache.
- Serverless (Lambda-based deployments): DynamoDB.
Note: Changing modes mid-flight will log out every currently-authenticated user because their existing session data lives in the old store. Plan a maintenance window for any mode change in production.