Platform and site INI settings

Most of what your sites need is already tuned sensibly out of the box, so you can happily ignore this whole page until you have a specific reason not to. But when you do want to change one thing — pin a search backend, opt out of a protection that's getting in your way, keep sessions alive longer — there are two small text files you can create in your own files, and BOA reads them for you. No control panel toggle, no support ticket, no root: you write a couple of lines into a file over SFTP and the change takes effect on its own.

There are two of these files, and the only difference is how wide the change reaches:

  • Platform file — sites/all/modules/boa_platform_control.ini. Applies to every site on that platform (that whole codebase).
  • Site file — sites/<your-domain>/modules/boa_site_control.ini. Applies to just that one site.

If you set the same option in both, the site file wins for that site — think of the platform file as the default and the site file as the exception. Everything else falls back to BOA's built-in default, which is what you get when neither file exists.

How to change a setting

The steps are the same for either file:

  1. Connect to your account over SFTP (the same login you use for your files — see Connecting to your account).
  2. Find the right folder:
    • for a whole platform, sites/all/modules/ inside that platform's codebase;
    • for one site, sites/<your-domain>/modules/ (the folder named after the site's main domain).
  3. Create a plain text file there named exactly boa_platform_control.ini (platform) or boa_site_control.ini (site). If one already exists, just edit it.
  4. Add one line per setting you want to change, in the form name = VALUE — for example session_cookie_ttl = 172800. Only add the lines you actually want to change; leave everything else out and BOA keeps its default for those.
  5. Save the file.

That's the whole job. You don't run anything and you don't need to click Verify in the control panel — BOA reads the file on the very next web request.

It takes about a minute. Your live sites keep their compiled settings warm for around 60 seconds for speed, so a change you save now shows up shortly after, not the instant you hit save. Give it a minute before deciding it didn't work.

Want to see exactly which values are live? BOA ships a template of each file with every option written out and explained, as comments, for reference — you'll find them at /data/conf/default.boa_platform_control.ini and /data/conf/default.boa_site_control.ini if your shell can reach them, or you can just use the tables below. On a site reached through its .dev. preview hostname, BOA also adds X-Ini-... response headers listing the active values, which is a handy way to confirm a change actually landed.

A note on format, so a small typo doesn't cost you an afternoon: the value keywords are written in UPPERCASE exactly as shown (TRUE, FALSE, YES, NO), one setting per line, no quotes needed around plain words or numbers. Anything you're not changing, simply leave out of the file.

Search: connect a Solr backend

These live in the site file only. They set up (and later protect or refresh) a Solr search core for one site. BOA's search helper checks these every few minutes, so a Solr core you ask for here appears within about 5–10 minutes rather than the next day.

Setting What it does Default
solr_integration_module Turns on a Solr core for this site and picks which integration module it's configured for. Use the module name that matches your Drupal version — search_api_solr9, search_api_solr7, search_api_solr (Solr 7), or the deprecated apachesolr (Solr 4). Remove the line to have the core cleanly deleted. (unset — no Solr core)
solr_update_config YES lets BOA refresh your core's schema.xml / solrconfig.xml when the integration module ships newer ones. Ignored if solr_custom_config = YES. NO
solr_custom_config YES protects your own hand-edited schema.xml / solrconfig.xml from being overwritten. On hosted BOA you supply the custom files through a support request; the setting just tells BOA to leave them alone. NO

You still need to add the search integration module (and its dependencies) to your own codebase — turning solr_integration_module on only creates and wires up the Solr core; it doesn't install Drupal modules for you. Once the core is ready, BOA writes a small sites/<your-domain>/solr.php file with the connection details for it.

Caching: page cache and microcache TTL

These work in either file. BOA's caching is already aggressive and fast, so reach for these only to solve a specific problem — a page that must never be cached, or a TTL you want a little longer.

Setting What it does Default
speed_booster_anon_cache_ttl How many seconds an anonymous visitor's page may be served from the Nginx front cache. Raising it means fewer trips into Drupal (faster, but content can look stale a little longer). Values of 10 or below are ignored. 10
disable_drupal_page_cache TRUE switches off Drupal's own full-page cache. Almost always the wrong move — it makes anonymous pages noticeably slower — so only touch it if a specific page genuinely must be built fresh for every anonymous visitor. FALSE

If only one URL needs to dodge the cache, don't disable page caching wholesale — it's much gentler to add a small exception for that path in your site's local.settings.php instead of turning caching off for the whole site.

Sessions: how long logins last

Both in either file. These control how long a logged-in session survives.

Setting What it does Default
session_cookie_ttl Session cookie lifetime, in seconds. Raise it to keep people logged in longer. 86400 (24 hours)
session_gc_eol How many seconds before an idle session is treated as stale and cleaned up (which logs that user out). 86400 (24 hours)

If you also use the built-in Session Expire module, keep session_cookie_ttl lower than the module's own timeout — the module deletes old session rows on cron regardless of the PHP setting, so a mismatch logs people out sooner than you'd expect.

Access control: opting out of built-in protections

These are the switches for BOA's default protections. The defaults are the safe choice — change one only when it's actively blocking something you need.

Some of these apply in either file, some only make sense per-site; the scope column below tells you which.

Setting Scope What it does Default
disable_admin_dos_protection site or platform By default, anonymous visitors hitting /admin* get redirected to the homepage — this keeps those never-cached URLs from being used to hammer your site. TRUE turns that redirect off. Worth flipping only if an expired session is bouncing you to the homepage when you should be logged in. FALSE
allow_anon_node_add site or platform TRUE lets anonymous visitors add (and edit) content. Almost always a bad idea; the default redirects them to the homepage. FALSE
ignore_user_register_protection site or platform By default BOA nudges Drupal 6/7 sites to a spam-safe registration policy ("administrator approval required" plus email verification) each morning. TRUE tells BOA to leave your registration settings exactly as you set them in the site admin. Only affects Drupal 6/7. FALSE
enable_strict_user_register_protection platform only TRUE forces the strictest registration policy ("Administrators only") on every Drupal 6/7 site on the platform. Ignored on any site whose site file sets ignore_user_register_protection = TRUE. FALSE
allow_private_file_downloads site or platform TRUE enables Drupal's private files mode. Only useful for sites that sell downloads or need strict per-file access control — it's slower, so leave it off otherwise. FALSE

The registration-protection behaviour runs during the nightly maintenance pass, not the moment you save the file — so a change here settles in by the next morning rather than within the minute, unlike the live settings above.

Redis / Valkey cache tuning

BOA's fast cache (Redis, or its drop-in replacement Valkey) is tuned well by default, and all of these keep the redis_ prefix even on a Valkey server. You'll rarely need them, but a few are genuinely useful when you're chasing a caching quirk. They work in either file.

Setting What it does Default
redis_exclude_bins A comma-separated list of cache bins to keep out of Redis/Valkey and serve from the database instead — handy when one misbehaving bin is fighting the cache. Example: redis_exclude_bins = "cache_form,cache_foo". (none excluded)
redis_cache_disable TRUE turns the fast cache off entirely for the affected sites. Really only for debugging a rare problem — leave it on for normal running. FALSE
redis_debug_header TRUE adds neutral X-Cache-... response headers so you can inspect cache state with a plain curl, no admin login needed. Turn it on while investigating, then off again. FALSE
redis_old_nine_mode TRUE only if you run Drupal 9 older than 9.3, to make the cache work again. FALSE
redis_old_eight_mode TRUE only if you run Drupal 8 older than 8.8. FALSE
redis_flush_forced_mode Drupal 6/7 only. On by default for extra speed; set FALSE if you hit random blank pages from cache entries expiring sooner than a module expected. TRUE

Daily maintenance behaviour

A couple of settings change what BOA's nightly housekeeping does. Neither takes effect the moment you save — they run as part of BOA's scheduled maintenance, so give each its stated cadence below rather than expecting an instant change.

Setting Scope What it does Default
sql_conversion_mode site or platform Set to innodb or myisam (lowercase) to have BOA convert this site's (or platform's) database tables to that engine. The conversion pass runs weekly, on Tuesday — and it re-runs every Tuesday even once everything is already converted, because the same pass also OPTIMIZEs the tables and catches any newly created ones. Leave as NO unless you specifically need a conversion. NO
fix_files_permissions_daily platform only BOA re-applies safe file permissions across the platform's sites each day. Set FALSE only if you manage the codebase in Git in a way that fights those changes — otherwise leave it on, or Aegir tasks may misbehave. TRUE

When a setting needs something you can't reach

Everything on this page you can do yourself, from your own files, over SFTP. A few related things can't be done from here — for example, supplying custom Solr schema.xml files when solr_custom_config = YES, or anything that touches the server itself. Those are handled by your host, so if a setting's description points at one of them, just open a support request and describe what you're after — that's the right (and only) way in.