Installation Requirements
To deploy the Visual Action Platform, there are various hardware and software requirements.
Hardware Requirements
A server is required to host the Visual Action Platform. Bare metal, on-premise server or virtual cloud servers may be used. The server must have resources capable of supporting a production WSGI or ASGI web server, your organization’s desired database deployment, and the estimated number of concurrent users that will access the Platform at a given time.
At a minimum, Visual Action recommends the following hardware specifications:
| Hardware | Minimum Specification |
|---|---|
| Processor (CPU) | Dual-core, 1.5 GHz |
| Memory | 4GB DDR4 2000 MHz |
| Storage | 20GB |
| LAN Interface | 100 Mbps |
| Power Supply (PSU) | 450W |
| Motherboard | Capable of supporting memory interface rates of 2000 MHz and multi-threaded CPU of 1.5GHz |
Please note, these are minimum requirements in order for the Platform deployment to function properly. Most likely, your deployment will require significantly different hardware specifications to comfortably support your user base.
Software Requirements
Server-side
The server must host a standard web server from which the Platform can be served to clients. While Visual Action recommends the use of Apache2 on Linux Debian, you may use any web server of choice that supports WSGI or ASGI. Please note that the steps in this guide will describe installation on a Linux Debian distribution using Apache2 with mod_wsgi. This guide will not describe server operating system (OS) installation or configuration or initial web server installation or configuration. It will only describe the configurations that must be made to support the Platform deployment. Information on installing Apache2 on Linux can be found here, and information on installing and enabling mod_wsgi can be found here.
The Visual Action Platform requires Python code to be executed on the server. There are also several Python libraries and modules that are required to be installed. Note: All packages in the below table are required, but you should begin by installing the ones highlighted in yellow. Most, if not all, of the non-highlighted packages will be automatically installed during the installation of the highlighted packages.
| Package | Minimum Version |
|---|---|
| asgiref | 3.10.0 |
| certifi | 2025.10.5 |
| cffi | 2.0.0 |
| charset-normalizer | 3.4.3 |
| cryptography | 46.0.2 |
| Django | 5.2.7 |
| django-phonenumber-field | 8.3.0 |
| django-phonenumbers | 1.0.1 |
| idna | 3.10 |
| jwt | 1.4.0 |
| mysql-connector-python | 9.4.0 |
| numpy | 2.3.3 |
| pandas | 2.3.3 |
| phonenumbers | 9.0.15 |
| pillow | 11.3.0 |
| psycopg2 | 2.9.11 |
| pycparser | 2.23 |
| PyJWT | 2.10.1 |
| pyodbc | 5.2.0 |
| python-dateutil | 2.9.0.post0 |
| python-dotenv | 1.1.1 |
| pytz | 2025.2 |
| requests | 2.32.5 |
| rules | 3.5 |
| six | 1.17.0 |
| sqlparse | 0.5.3 |
| tzdata | 2025.2 |
| urllib3 | 2.5.0 |
Client-side
The only software required on client systems is a web browser. The browser must be capable of rendering webpages using HTML5 and CSS3, support and have enabled JavaScript, and support and enforce secure connections over HTTPS.
Visual Action recommends the use of Mozilla Firefox or Google Chrome.
Deployment
There are several steps involved in deploying the Visual Action Platform to ensure proper and secure operation. Please follow the steps in this guide carefully to ensure successful deployment.
If following these steps does not allow you to successfully launch the Platform, refer to the Django deployment checklist for additional information about configurations you may need to make.
1. Install Platform files.
Initially, you will need to choose an appropriate location to store the files associated with the Visual Action Platform. You may choose where to deploy the files, but they should be deployed in a non-public directory on your server, where proper access controls may be assigned.
Download the desired release of the Visual Action Platform here. Once downloaded, extract the contents of the archive to the directory where you want the Platform to be stored.
By default, the extracted software will be contained in a subdirectory called visual-action-platform.
2. Grant appropriate permissions.
In order to function properly, the web server hosting the Platform will need certain permissions to be able to interact with Platform files properly.
Navigate to the directory where you extracted the Platform files.
Run the following command, where [currentuser] is replaced with your username:
$ sudo chown -R [currentuser]:www-data visual-action-platform/
This will make all files and directories within (and including) visual-action-platform owned by you, and owned by the group www-data (Apache2’s group on Linux Debian). You may change this option accordingly for your web server.
Next, run the following command:
$ sudo chmod -R 775 visual-action-platform/
This will enable both the owner and members of the group www-data to read, write, and execute files within visual-action-platform. Users will only be permitted to read and execute.
If you change the location of the visual-action-platform directory, ensure that the corresponding permissions are set in the new location.
3. Generate a secret key.
The Platform uses a secret key to help defend the deployment from several potential attacks.
A few important notes about the secret key used in your deployment:
- The secret key should be a unique key that isn’t used for anything else.
- The secret key can be anything you want, but it is recommended that it is generated by a secure encryption algorithm.
- The secret key should be at minimum 50 characters, and feature significant variation in characters used.
- The secret key should be strongly protected, as exposure of the secret key could make your deployment vulnerable from several attack vectors.
- The secret key should not be hardcoded, whenever possible, although the deployment will function if it is hardcoded in the settings file.
- The secret key used in your production deployment should never be committed to source control (e.g.: Git).
Using your preferred encryption algorithm, generate a secret key to be used in your deployment.
The secret key will be included using the settings.py file, found in the visual-action-platform/vap/ directory.
While it is not recommended, you may paste the newly-generated secret into the settings.py file, assigning it to the variable named SECRET_KEY. This is NOT recommended, but will work.
The preferred – and more secure – procedure is to set an environment variable within your OS, and fetch that environment variable within the Platform’s settings file. To set the environment variable for your secret key in Linux Debian, run the following commands, replacing [your_secret_key] with the key you just generated:
$ SECRET_KEY='[your_secret_key]'
Then, to make it available to the software:
$ export SECRET_KEY
The Platform is already configured with python-dotenv, so if you prefer to use a local environment variable file (.env) in the Platform directory as opposed to a system or user variable, you may. For example, in your .env file, you would enter the following for your secret key:
SECRET_KEY="[your_secret_key]"
There is already a placeholder .env included in the Platform files root directory that you can use, or you may create your own elsewhere. Either way, be sure to change the following line in settings.py to reference the path to the .env file you are using:
load_dotenv('.env')
Change the contents of the string in the parentheses (.env in the example above) to the path to your .env file. Make sure to leave the quotation marks!
You may change the environment variable name to something other than SECRET_KEY if you want to use a different variable name or if it conflicts with a key used by other software.
Open the settings.py file from visual-action-platform/vap/. Locate the line that says:
SECRET_KEY = os.getenv('SECRET_KEY')
If you named your environment variable SECRET_KEY, and this line appears exactly as above in your settings.py file, don’t change anything.
If you used a different variable name for your environment variable, update only the value in the quotations to match your environment variable name. For example, if you named your variable SECRET_KEY_VAP, update the above line to:
SECRET_KEY = os.getenv('SECRET_KEY')
If for any other reason, the line does not match what you see above, update it to match.
4. Ensure debugging is off.
In your settings.py file, look for the variable named DEBUG. Ensure it is set to False.
Debugging mode should only be used in development; it reduces performance and will reveal information about your server and deployment that may assist attackers, should an error occur.
5. Configure allowed hosts.
When debugging mode is off in a Django application (which it should be for production), a set of allowed hosts must be specified, telling the deployment from which domains it may serve the application. This helps prevent forgery attacks.
In your settings.py file, locate the ALLOWED_HOSTS variable. To the right, it should be assigned and empty array [].
Inside the array, add strings containing the IP address and domain names of the hosts from which you want to allow serving the Platform. For example, if your server has an IP address of 127.0.0.1, and your domain name is example.com, you would enter (don’t forget quotes around your strings!):
ALLOWED_HOSTS = ['127.0.0.1','example.com']
6. Configure database connection and migrate.
The Platform supports multiple common databases as the backend support for the Platform. Each database has slightly different parameters for allowing Django to connect to it. Follow the steps here to configure your settings.py file to connect properly to your database.
Once Django is successfully connected to your database, navigate your terminal to the visual-action-platform/ directory, and run the following commands to ensure that your database is set up with the tables and data it needs for the Platform:
$ python manage.py makemigrations
$ python manage.py migrate
You may need to replace python with python3 or another command to use the appropriate Python installation on your server, depending on how it is configured.
7. Configure static files.
Your web server will serve static files normally, even though Django is generating the pages that users will see.
All of the static files that the Platform requires are contained in the visual-action-platform/static/ directory. If desired, move this directory to the location from which you would like to serve static files.
In your settings.py file, add the following line, replacing [path_to_static_files] with the absolute path to your static files directory.
STATIC_ROOT = "[path_to_static_files]"
Save the settings.py file.
In your terminal, navigate to the visual-action-platform/ directory, and run the following command:
$ python manage.py collectstatic
This will allow Django to collect the static files and efficiently serve them when users navigate to the Platform.
8. Ensure security features are enabled.
In settings.py, make sure the following variables are set to True.
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True
9. Configure deployment details.
Near the top of the settings.py file, set the Deployment ID and Entity Name fields to the appropriate values.
DEPLOYMENT_ID = "[your_deployment_id]"
ENTITY_NAME = "[your_organization_name]"
If you’ve been given a specific Deployment ID from Visual Action, enter that for DEPLOYMENT_ID. If you haven’t been given one, create an appropriate Deployment ID. A good way to produce a deployment ID is to use a combination of the primary letters in your organization name, concatenated with the abbreviation of the software (VAP). This helps you quickly identify what the ID represents, while also making it distinguishable from other IDs you may use in other software. For example, if your organizations name is “My Company”, you might use MC_VAP or VAP_MC for your Deployment ID. If you have more than one Visual Action Platform deployment, consider appending a number to your Deployment ID indicating which deployment it refers to.
Enter your organizations full formal name for the ENTITY_NAME field.
10. Configure SSO, if applicable.
If your deployment will use SSO to authenticate Platform users, you must connect the Platform to your user pool.
First, determine whether password authentication will still be permitted, or if users may only authenticate using SSO. You can enable or disable both forms of authentication in settings.py by adjusted the following keys to either True or False. At least one must be enabled.
PASSWORD_AUTH_ENABLED = False
JWT_AUTH_ENABLED = True
By default, the Platform will not allow the automatic creation of new users, even if they are accessing the Platform with a valid organizational account. You may want to keep it this way, if an administrator must manually approve all account creations.
If you’d like the Platform to automatically register new users, enter the domain of the email address that would be associated with that user in the SSO_CREATE_USERS_WITH_MATCH_DOMAIN field. This tells the Platform that new users who successfully authenticate with SSO and who have a matching domain in their email should automatically be registered with a new account in the Platform.
Example: SSO_CREATE_USERS_WITH_MATCHING_DOMAIN = "@visualaction.com"
In the above example, replace “visualaction.com” with your organization’s (email) domain. Don’t forget to include the @ symbol at the beginning.
Finally, there are four pieces of information that must be entered to allow the Platform to communicate with your identity provider (IdP). You may use any IdP, as long as it supports JWT). The Platform leverages Amazon Cognito, so you may also use an existing Cognito user pool or have Visual Action manage a user pool for you.
Similar to the SECRET_KEY and API Keys, you may enter these values directly into settings.py, but it is recommended that you use environment variables. The settings.py file is configured by default to fetch from an environment variable for each value. If you don’t want to use environment variables, replace the os.getenv([variable name]) with a string value. If you want to use environment variables, open the .env file and enter your connection details as follows:
JWT_AUTH_KEYS_URL = "[Your IdP’s authentication keys URL]"
JWT_AUTH_ISSUER = "[Your IdP’s issuer URL]"
JWT_AUTH_AUDIENCE = "[The ID of the user pool you want to use for the Platform]"
JWT_AUTH_LOGIN_URL = "[Authentication URL with return page generated by your IdP]"
Once you’ve configured these variables accordingly, you can save you changes to settings.py and your .env file. SSO authentication is now configured.
11. Configure web server to serve the Platform to clients.
Finally, your web server needs to know that it should serve the Platform to users when they visit a particular URL.
For Apache2, open the configuration (.conf) file for the site at which you want your Platform deployment served. Add the following lines to that file, inside the corresponding VirtualHost directive, replacing [path_to_static_root] with the absolute path to your static files directory, and replacing [path_to_platform_deployment] with the absolute path to your Platform files directory:
Alias /static [path_to_static_root]
<Directory [path_to_static_root] >
Require all granted
</Directory>
<Directory [path_to_platform_deployment]/vap/ >
<Files wsgi.py>
Require all granted
</Files>
</Directory>
Save the configuration file, test Apache2’s configuration, and reload the web server.
Once you’ve completed these deployment steps, reload your web server and test access. You should have a working Platform deployment!
The Visual Action Platform installation files come with an already-migrated database in SQLite3. If you are connecting to a different database than the default, you will need to configure settings.py according to the Django Database Instructions. You will also need to migrate the Platform’s schema to the database. To do so, run the following commands once you have hooked the Platform into your database:
$ python manage.py makemigrations
$ python manage.py migrate
It is likely that the makemigrations command will tell you that no changes have been detected. This is okay and is the normal output if no Platform files have been changed.
The default Platform deployment includes one superuser account, intended for an admin to use to log in and manage accounts once the Platform has been installed and deployed. Both the username and password for this account are vap_admin. It is highly recommended that you create a new superuser account with your own credentials and delete this default account as soon as you can log in to the Platform. The Platform can be managed by administrators at the /admin endpoint ([your_platform_url]/admin).