Advanced configuration
Some features and behaviors of YAFFA can be configured to your needs. This section describes the advanced settings and how to configure them.
Configuration
The settings of YAFFA are stored in a .env file. This file is not part of the repository and is created during the installation process. You can find a sample file in the root of the YAFFA folder, named .env.example. This file contains all the settings that YAFFA uses, but with default values.
User limit
You can decide if you want to limit the number of users that can register in your YAFFA instance. This is a smaller extra security measure to prevent unauthorized useage of your environment, if it is accessible from the internet or for any other users locally.
# The maximum number of users that can be registered in the system.
# For a personal instance, you can set this to 1 to prevent other people from registering.
# Increase this value if you want to allow other users to register, or set it to empty to allow unlimited registrations.
REGISTERED_USER_LIMIT=1
User verification
By default, users need to verify their email address before they can log in to YAFFA. If you want to disable this feature, you can set the following value to false.
Make sure to configure outgoing emails if you enable this feature, as new users won't be able to log in otherwise.
# Do new users have to verify their email address before they can log in?
# For a local, personal instance, without access to outgoing emails, this should be set to false.
# For a public instance, this should probably be set to true.
EMAIL_VERIFICATION_REQUIRED=FALSE
Application URL
YAFFA needs to know the URL under which it is accessible. This is important for generating links in emails and other parts of the application. Make sure to set this value to the correct URL.
# The URL of the application, used for generating links in emails
APP_URL=http://localhost
Trusted proxies
If YAFFA runs behind a reverse proxy (a load balancer, Nginx Proxy Manager, Traefik, nginx, Apache, etc.), it needs to know which proxy IPs it can trust to determine the client's real IP address. This is also a prerequisite for YAFFA to trust the proxy's X-Forwarded-Proto header and generate correct https:// URLs - without it, you may see mixed-content errors even though APP_URL is set to https://.
# A comma-separated list of trusted proxy IPs/CIDR ranges, or * to trust any proxy.
TRUSTED_PROXIES=*
If you're putting YAFFA behind your own reverse proxy instead of the Docker Compose setup's optional Caddy service, see Running YAFFA behind a custom reverse proxy for the full setup, including proxy-side configuration.
Administrator email
If you configured outgoing emails, you can set the email address of the administrator. This email address will receive notifications about users logging in to your YAFFA instance.
# The email address of the administrator of the system, who will receive notifications about new users, logins, etc.
# Leave this empty if you don't want to receive any notifications
ADMIN_EMAIL=
Application key
The application key protects your sessions and encrypted data, such as two-factor authentication secrets. In the Docker setup, you can leave APP_KEY empty: on first start, the container generates a key and keeps it in the storage volume (storage/app/.app_key), so restarts and container re-creation keep using the same key. If you set APP_KEY yourself, that value is used.
# Leave empty with Docker to let the container generate and persist a key.
# Don't change it after you have started using the application.
APP_KEY=
Don't delete the storage volume without keeping a copy of the key. See backing up Docker volumes. If you install without Docker, generate the key with php artisan key:generate.
Cache, Redis, and session names
Since YAFFA 4.0 (Laravel 13), the default names of the cache prefix, the Redis prefix, and the session cookie are built differently, unless you set them explicitly. To keep existing cache, queue, and session data across an upgrade, make sure your .env contains these lines. New installations get them from .env.example.
CACHE_PREFIX=yaffa_cache_
REDIS_PREFIX=yaffa_database_
SESSION_COOKIE=yaffa_session
Cache, queue, and session drivers
YAFFA stores its cache, its background job queue, and the user sessions using the drivers below. The .env.example file, and with it the Docker setup, uses Redis for all three, and the Docker Compose file includes a Redis service. Redis is optional: YAFFA does not depend on Redis-specific features, so you can use the simpler options if you don't want to run Redis.
CACHE_STORE=file
QUEUE_CONNECTION=database
SESSION_DRIVER=file
| Setting | Works without Redis | Notes |
|---|---|---|
QUEUE_CONNECTION=database | Yes | The required tables are created by the regular migrations. A queue worker is still needed. |
CACHE_STORE=file | Yes | The web server and the queue worker must share the same storage folder, which is the case in the usual setups. |
SESSION_DRIVER=file | Yes | Same note as for the cache. |
CACHE_STORE=database, SESSION_DRIVER=database | Only with extra migrations | The tables are not part of YAFFA's migrations. |
CACHE_STORE=array, QUEUE_CONNECTION=sync | Not for production | The array cache is not shared between the web server and the queue worker, which breaks locks and rate limiting. With the sync queue, tasks such as price retrieval and AI processing run within your web requests. |
Changing the session driver logs out every user once. If you use the Docker setup without Redis, also remove the redis service and its depends_on entries from your docker-compose.yml file.
Scheduler
Scheduled tasks (see cron jobs) should run on exactly one instance of YAFFA. This is controlled by the following setting. In the Docker Compose setup, the file sets it per service, so the scheduler container runs the tasks, and the app container does not.
RUNS_SCHEDULER=TRUE
API access
Users can create personal API tokens in their settings, see API access. You can limit how long a token can be valid, and decide who can see the automatically generated API documentation.
# Maximum lifetime (in days) a user can choose when creating a personal access token.
API_TOKEN_MAX_LIFETIME_DAYS=365
# Who can view the API documentation at /docs/api on a non-local environment?
# none - always denied (default)
# user - allowed for authenticated, email-verified users only
# guest - allowed for anyone
# SCRAMBLE_PROD_AUTH=none