# Self-Hosting Specify 7 **URL:** \ **Category:** Configuration & Installation\ **Tags:** Specify-7, Members-only\ **Created:** [June 5, 2025, 2:55am UTC](https://speciforum.org/t/self-hosting-specify-7/2591 "2025-06-05T02:55:30Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![jason\_m](https://avatars.discourse-cdn.com/v4/letter/j/8e8cbc/32.png) [@jason\_m](https://speciforum.org/u/jason_m)\ **Post date:** [June 5, 2025, 2:55am UTC](https://speciforum.org/t/self-hosting-specify-7/2591/1 "2025-06-05T02:55:30Z")
> 📖 This guide describes how to self-host an environment of Specify 7. > > ⚙ This guide is intended for technical or IT users only. > [!info] > 💭 **Before you begin,** consider that the Specify Collections Consortium (SCC) offers the **Specify Cloud** hosting service to members of the consortium. > > By choosing SCC’s Specify Cloud hosting, you get a fully managed Specify 7 environment with automatic updates, priority support, and low-latency servers in cloud regions around the world. Daily backups of your database and attachments ensure your data is always protected, and optional add-ons—like scalable digital asset storage and direct SQL access—give your IT team the flexibility they need without the extra maintenance overhead. > > If you’d like pricing details or to discuss an evaluation period, please see our [services prices](https://speciforum.org/t/specify-membership-and-technical-support-services-prices/2601) or get in touch at [membership@specifysoftware.org](mailto:membership@specifysoftware.org). We’d love to help you turn over the sysadmin headaches and focus on what you do best—advancing collection‐based research. ## Introduction This approach means that your IT support will need to be responsible for managing the server hosting Specify and the associated assets, updates, and day-to-day accesss troubleshooting. We ask that all SCC members use our containerized compositions of Specify 7, available for both [Docker](https://www.docker.com/get-started/) and [Podman](https://podman.io/). **[📨 Click here to request access](mailto:support@specifysoftware.org?subject=Requesting%20Docker%20Repository%20Access&body=My%20GitHub%20username%20is%3A%20%0D%0AMy%20Specify%20Member%20Institution%20is%3A%20%0D%0AAdditional%20Questions%20or%20Notes%3A%20), including your GitHub username, member institution, collection, and any additional questions or notes you have for us.** > [@Specify 7 Installation Instructions](https://speciforum.org/t/specify-7-installation-instructions/755): > > open_book This guide provides a concise, up-to-date overview for installing and running Specify 7 using the compose recipes in this repository (Docker and Podman). gear These instructions should be followed by an IT administrator. Overview This repository contains container compose recipes for deploying Specify 7 in a few common scenarios. Content is grouped under docker/ and podman/ and includes: An “all-in-one” composition (app, DB, asset server, web) for small or evaluation install… ## Getting Started We recommend using containerization to host Specify 7 (as well as hosting the [Report Runner](https://github.com/specify/report-runner-service) and [Web Asset Server](https://github.com/specify/web-asset-server) services). Both [Docker](https://www.docker.com/get-started/) and [Podman](https://podman.io/) are supported container runtimes. Containerization allows each service to be “containerized” or in other words, generally isolated from the host computer. This means each container is in charge of its dependencies and only the container runtime is required to be installed for each containerized service. For the Specify database, you can either create a new database directly with Specify 7 or connect Specify 7 to an existing database that was created or updated to Specify 6.8.03. Databases from earlier Specify 6 releases are not supported. ### Service and Architecture Overview Because Specify 7 is a webservice, there are a number of separate services or components which act and communicate together to provide the entire Specify suite of functionality. You can learn more about the software architecture in the following topic: > [@Specify 7 Architecture Overview](https://speciforum.org/t/specify-7-architecture-overview/2590): > > book This guide provides a brief overview of the Specify 7 architecture, lists the system features, and includes a diagram of the system architecture. Specify 7 is an open-source, modular platform for managing biological and geological collections, supporting both on-premises and cloud deployments. Specify features a modern, fully decoupled architecture with a strong emphasis on flexibility, scalability, and maintainability. Architecture Description The Specify 7 platform separates front-e… ### Recommended Server Specifications > [@Specify 7 Recommended Server Specifications](https://speciforum.org/t/specify-7-recommended-server-specifications/2334): > > book This guide outlines the minimum required server specifications if you are planning on self-hosting Specify 7. [!warning] This guide is for IT staff only. If you are a collection manager or staff member interested in evaluating Specify 7, please contact [membership@specifysoftware.org](mailto:membership@specifysoftware.org) for more information! We recommend that interested users with limited IT staff join the [Specify Cloud](https://speciforum.org/t/what-is-specify-cloud/714) hosting service. The Specify Collections Consortium team can host and manage Specify 7 installations … ## Specify 7 Components ### Specify 7 **Code Source:** [https://github.com/specify/specify7](https://github.com/specify/specify7) **Container Images:** [https://hub.docker.com/r/specifyconsortium/specify7-service/tags](https://hub.docker.com/r/specifyconsortium/specify7-service/tags) The primary frontend and backend of the Specify 7 application. Specifically, it contains a [Django](https://www.djangoproject.com/) web framework for processing web requests. Once the initial server-provided web-page is loaded, rendering is handled client-side via [React](https://react.dev/) and [React Router](https://reactrouter.com/). Traditionally, the Web Server Gateway Interface (WSGI) [Gunicorn](https://gunicorn.org/) is used to forward web-server requests to Django. At runtime, Django configuration settings for the Specify installation are read from the [specifyweb/settings/\_\_init\_\_.py](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/specifyweb/settings/ __init__.py) file. This file generally expects the user-configured settings to be present within a `local_specify_settings.py` file in the same directory. Possible user-configurable variables can be found within the [specify\_settings.py](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/specifyweb/settings/specify_settings.py) file. For local non-containerized installations, this file is copied and renamed to `local_specify_settings.py` (see [Adjusting Settings Files](https://github.com/specify/specify7/tree/main?tab=readme-ov-file#adjusting-settings-files)). > [!tip] > If you are looking for how to install Specify 7 via Docker, skip ahead to **[Specify 7 Example Docker Compose Configurations](https://speciforum.org/t/self-hosting-specify-7/2591#p-5023-example-docker-compose-configurations-22)**. When building Specify 7 using the provided [Dockerfile](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/Dockerfile) or when using any of the built images hosted on Docker Hub ([https://hub.docker.com/r/specifyconsortium/specify7-service/tags](https://hub.docker.com/r/specifyconsortium/specify7-service/tags)), these user-configurable variables are read from the container environment variables and copied into `local_specify_settings.py`. **Example commands to start the Specify 7 Service:** ```bash # Apply the initial Specify migration if not already applied ve/bin/python manage.py base_specify_migration # Apply any normal migrations ve/bin/python manage.py migrate # Start the WSGI Server + Django ve/bin/gunicorn -w 3 -b 0.0.0.0:8000 -t 300 specifyweb_wsgi ``` See [Dockerfile#L225](https://github.com/specify/specify7/blob/cfa72aca21f4fea890e8ce8991ff8c20ce276b9d/Dockerfile#L225), [docker-entrypoint.sh](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/docker-entrypoint.sh), and [specifyweb.wsgi](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/specifyweb.wsgi). When using a built image from the [Specify 7 Image repository](https://hub.docker.com/r/specifyconsortium/specify7-service/tags%20), these commands are executed automatically on container startup. ### Specify 7 Worker Potentially computationally expensive, asynchronous, or otherwise slow operations in the main Specify application are commonly passed to a separate task queue (traditionally [Celery](https://docs.celeryq.dev/en/stable/index.html)), through a message broker (commonly [Redis](https://redis.io/)). **Redis Container Images:** [https://hub.docker.com/\_/redis](https://hub.docker.com/_/redis) Architecturally, the Specify 7 Worker is usually identical to the primary Specify 7 service. The Celery worker can be started from the Specify 7 Worker instance via the following command (which is commonly included within a compose file for the Specify 7 Worker service) : ```auto command: bash -c "ve/bin/celery -A specifyweb worker -l INFO --concurrency=1" ``` For more information regarding using Celery from the command line, view the Celery documentation at [https://docs.celeryq.dev/en/latest/userguide/workers.html](https://docs.celeryq.dev/en/latest/userguide/workers.html). Additional information regarding Celery and Django (including the CELERY\_BROKER\_URL and CELERY\_RESULT\_BACKEND variables) can be found at: [celery/docs/django/first-steps-with-django.rst at main](https://github.com/celery/celery/blob/7135768008f982f96cb11e6061d3b309be374583/docs/django/first-steps-with-django.rst) ### Specify 7 and Worker Configuration #### Supported Customization / Environment Variables | Variable Name | Description | Default / Example Value | | --- | --- | --- | | DATABASE\_HOST | Hostname or IP of the server hosting the database | localhost | | DATABASE\_PORT | The port number of the database application | 3306 | | DATABASE\_NAME | The name of the database to connect to within the database application | SpecifyDB | | MASTER\_NAME | The username of the database user which the Specify application will act as | MasterUser | | MASTER\_PASSWORD | The password of the database user which the Specify application will act as | MasterPassword | | SECRET\_KEY | An unpredictable, unique key that Django uses for cryptographic signing. See Django’s [SECRET\_KEY](https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-SECRET_KEY) | | | ASSET\_SERVER\_URL | The complete url to the `web_asset_store.xml` of the Attachment Server service | [http://host.docker.internal/web\_asset\_store.xml](http://host.docker.internal/web_asset_store.xml) | | ASSET\_SERVER\_KEY | The configured ATTACHMENT\_KEY of the Attachment Server service | | | REPORT\_RUNNER\_HOST | The hostname or IP of the Report Runner service | report-runner | | REPORT\_RUNNER\_PORT | The port number of the report runner application | 8080 | | CELERY\_BROKER\_URL | The URL of the message broker celery will use to send and receive messages. See Celery’s [broker\_url](https://docs.celeryq.dev/en/stable/userguide/configuration.html#broker-url) | redis://localhost/0 | | CELERY\_RESULT\_BACKEND | The backend used to store task results. See Celery’s [result\_backend](https://docs.celeryq.dev/en/stable/userguide/configuration.html#result-backend) | redis://localhost/1 | | LOG\_LEVEL | The logging level mask for the Specify 7 backend. All logging statements for levels below | WARNING (possible values: DEBUG, INFO, WARNING, ERROR, CRITICAL) | | SP7\_DEBUG | Whether Django is run in DEBUG mode. See Django’s [DEBUG](https://docs.djangoproject.com/en/5.2/ref/settings/#std-setting-DEBUG) | true (or false) | | SPECIFY\_CONFIG\_DIR | A file path to a Specify configuration directory containing Specify-specific configuration files. For legacy migrations, this may point at an existing Specify 6 `config` directory. | /opt/Specify/config | | ALLOWED\_HOSTS | A comma-separated list of hosts and/or domains that Specify can serve to. `*` denotes all hosts, and a period can be used as a wildcard to match against subdomains. See Django’s [ALLOWED\_HOSTS](https://docs.djangoproject.com/en/4.2/ref/settings/#allowed-hosts) | \*,localhost,.specifycloud.org | | CSRF\_TRUSTED\_ORIGINS | A comma-separated list of trusted origins for unsafe requests that can create, modify, or delete data (POST, PUT, DELETE, etc.). `*` can be used a wildcard to match against subdomains. The scheme (http://, https://) MUST be included in each origin. See Django’s [CSRF\_TRUSTED\_ORIGINS](https://docs.djangoproject.com/en/4.2/ref/settings/#csrf-trusted-origins) | http://\*,https://\*,https://\*.specifycloud.org | | ANONYMOUS\_USER | You can provide the name of a specify user for anonymous access to the instance. This user will have all of the permissions given to that user, so make sure to configure this carefully. [Documentation](https://speciforum.org/t/enable-anonymous-guest-access-in-specify-7/992). | GuestUser | | TIME\_ZONE | The time zone for the Specify instance used on the backend can be any from the list of [TZ identifiers](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). This is used for fetching notifications, timestamps, and more. | America/Chicago | #### Security > [!warning] > The provided Specify 7 defaults should not be considered secure. The section below outlines some security-related variables and their use within the application. Before setting up a production-ready environment, review each variable and modify it if needed ##### SECRET\_KEY Source: [Django | Settings | SECRET\_KEY](https://docs.djangoproject.com/en/4.2/ref/settings/#secret-key) The SECRET\_KEY is used internally by Django and Specify to verify and manage [Sessions](https://docs.djangoproject.com/en/4.2/topics/http/sessions/), manage and store OAuthLogin (SSO) information within the session, and for [Cryptographic Signing](https://docs.djangoproject.com/en/4.2/topics/signing/#module-django.core.signing) of data. The value of the SECRET\_KEY should be changed from the default and kept secret. As stated by Django in the SECRET\_KEY documentation: > [!caution] Keep this value secret > > Running Django with a known [`SECRET_KEY`](https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-SECRET_KEY) defeats many of Django’s security protections, and can lead to privilege escalation and remote code execution vulnerabilities. ##### ALLOWED\_HOSTS **Source:** [Django | Settings | ALLOWED\_HOSTS](https://docs.djangoproject.com/en/4.2/ref/settings/#allowed-hosts) **Default:** \* As an environment variable, Specify expects ALLOWED\_HOSTS to be a comma-separated list of host and/or domain names. The list of host and/or domain names are the servers that Specify (through Django) is able to serve. Any host which is not present in this list which attempts to utilize Specify will receive a 400 Bad Request and not be able to access the requested resource. Configuring this setting to a limited number of hosts you know will access Specify will achieve [Host header validation](https://docs.djangoproject.com/en/4.2/topics/security/#host-headers-virtual-hosting), and aim to prevent Host header attacks. Values in the list can be fully qualified domain names (like `www.example.com`) or a portion of a domain name beginning with a period (like `.example.com`). Values beginning with a period are treated as subdomain wildcards. So `.example.com` would match any subdomain of `example.com`: `www.example.com`, `test.example.com`, etc.). The special value `*` can be provided to allow all hosts. > [!warning] > The default ALLOWED\_HOSTS - `*` - is insecure and allows all hosts to connect with the Specify instance. > > Before deploying Specify in a production environment, modify this setting to the host or list of hosts that are expected to utilize the Specify instance. ##### CSRF\_TRUSTED\_ORIGINS **Source:** [Django | Settings | CSRF\_TRUSTED\_ORIGINS](https://docs.djangoproject.com/en/4.2/ref/settings/#csrf-trusted-origins) **Default:** http://\*, https://\* As an environment variable, Specify expects CSRF\_TRUSTED\_ORIGINS to be a comma-separated list of domain names (which must include the scheme of either http or https). Values in the list represent trusted domains from which unsafe requests can originate. An unsafe request is one that create, modify, or delete data (POST, PUT, and DELETE requests). Similarly to ALLOWED\_HOSTS, if an unsafe request originates from a domain that is not present in the CSRF\_TRUSTED\_ORIGINS, then it will be rejected with a CSRF Verification failed response. ⚠ The default CSRF\_TRUSTED\_ORIGINS - http://\*, https://\* - is insecure and trusts all hosts for sending unsafe requests. Before deploying Specify in a production environment, modify this setting to the domain or list of domains that are expected to send unsafe requests. ### MariaDB (Database) The MariaDB service provides the database for Specify 7. By default, MariaDB listens on port 3306. At this time, there are no other supported database management systems available for Specify 7. **This can be managed in a Docker container or externally.** Specify automatically handles database setup and migrations on startup. The setup process includes the following steps: - It waits until the DB is reachable at `DATABASE_HOST:DATABASE_PORT` - Validate master credentials (`MASTER_NAME`, `MASTER_PASSWORD`, or `MYSQL_ROOT_PASSWORD`) - Create the target database (`DATABASE_NAME`) if it is missing - Create/verify migrator and app users and per-host entries - Grant required privileges (migrator gets ALL; app gets application permissions) - Run Django migrations via: - `manage.py base_specify_migration --use-override --database=` (existing DB) - `manage.py base_specify_migration --database=` (new DB) - `manage.py migrate --database=` `` is usually `migrations` unless the migrator is the same as master, in which case it may switch to `master`. #### Current DB setup environment variables | Variable Name | Description | Default / Notes | | --- | --- | --- | | DATABASE\_HOST | MariaDB host | required | | DATABASE\_PORT | MariaDB port | required | | DATABASE\_NAME | Application database name | required | | MYSQL\_ROOT\_PASSWORD | Root password for MariaDB | required if MASTER\_PASSWORD unset | | MASTER\_NAME | Master DB user name | root (default) | | MASTER\_PASSWORD | Master DB password | falls back to MYSQL\_ROOT\_PASSWORD | | MASTER\_HOST | Master DB host pattern | `%` (default) | | MIGRATOR\_NAME | Migrator DB user name | falls back to MASTER\_NAME | | MIGRATOR\_PASSWORD | Migrator DB password | falls back to MASTER\_PASSWORD | | MIGRATOR\_HOST | Migrator DB host pattern | `%` (default) | | APP\_USER\_NAME | App DB user name | falls back to MIGRATOR\_NAME | | APP\_USER\_PASSWORD | App DB password | falls back to MIGRATOR\_PASSWORD | | APP\_HOST | App DB host pattern | `%` (default) | #### Permission logic - If migrator and master credentials are identical, migrator creation/grants are skipped and cooldown alias may use `master`. - If app and master credentials are identical, app creation/grants are skipped. - If app and migrator credentials are identical, app creation/grants are skipped. #### Required app privileges The setup script grants these permissions for app user on `DATABASE_NAME.*`: `SELECT`, `INSERT`, `UPDATE`, `ALTER`, `INDEX`, `DELETE`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`. #### Required migrator privileges The setup script grants `ALL PRIVILEGES` on `DATABASE_NAME.*`. ### Attachment Server Source Code: [https://github.com/specify/web-asset-server](https://github.com/specify/web-asset-server) Docker Hub (Includes available Images): [https://hub.docker.com/r/specifyconsortium/specify-asset-service](https://hub.docker.com/r/specifyconsortium/specify-asset-service) Documentation: [https://speciforum.org/t/web-asset-server-attachment-server/657](https://speciforum.org/t/web-asset-server-attachment-server/657) This is our official attachment server implementation for Specify. This implementation is targeted at Ubuntu flavors, but will work with minor modifications on other Linux systems. #### Supported Customization / Environment Variables | Variable Name | Description | Default Value | | --- | --- | --- | | SERVER\_NAME | The hostname or IP (and optional path) at which the asset server is publicly accessible. | | | SERVER\_PORT | The TCP port on which the server listens for incoming HTTP requests. | 80 | | ATTACHMENT\_KEY | A shared secret key used to authenticate requests between the Specify 7 service and the asset server service. | | | DEBUG\_MODE | Enable verbose logging and error output. Set to `true` for development, `false` for production. | false | ### Report Runner Source Code: [https://github.com/specify/report-runner-service](https://github.com/specify/report-runner-service) Docker Hub (Includes available Images): [https://hub.docker.com/r/specifyconsortium/report-runner](https://hub.docker.com/r/specifyconsortium/report-runner) The Specify Report Runner is a simple web service wrapper around the Jasper Reports libraries for report and label generation in Specify 7. It generates reports for Specify 7 via a REST endpoint. #### Supported Customization / Environment Variables | Variable Name | Description | Default Value | | --- | --- | --- | | REPORT\_RUNNER\_HOST | Hostname or IP address (container name or network alias) where the report-runner service is reachable. | report-runner | | REPORT\_RUNNER\_PORT | TCP port on which the report-runner service listens. | 8080 | | LOG\_LEVEL | Minimum log level for the report-runner process (`DEBUG`, `INFO`, `WARNING`, `ERROR`, or `CRITICAL`). | INFO | | SP7\_DEBUG | Enable debug mode in integrated components (affects verbose output). | false | ### Web Server / Reverse Proxy Docker Hub (Includes available Images): [https://hub.docker.com/\_/nginx](https://hub.docker.com/_/nginx) We recommend and commonly utilize [NGINX](https://nginx.org/) as a webserver and reverse proxy. As a reverse proxy, it’s important to forward requests meant for the asset server (see the routes in [web-asset-server/server.py#L212-361](https://github.com/specify/web-asset-server/blob/3e1847646df6cb0d7e95d6f72bf1b86916a16b27/server.py#L212-L361)) to the correct hostname and port, as well as serving static files directly to the requesting client. All other requests can be forwarded to the main Specify 7 service. **Simple example NGINX configuration for Specify 7:** See [docker/all-in-one/nginx.conf](https://github.com/specify/docker-compositions/blob/production/docker/all-in-one/nginx.conf) or [podman/all-in-one/nginx.conf](https://github.com/specify/docker-compositions/blob/production/podman/all-in-one/nginx.conf), or refer to [specify7/nginx.conf](https://github.com/specify/specify7/blob/576e02b7107e207057282602d5903861682ce4df/nginx.conf) ## Example Container Compose Configurations Below are example compositions for self-hosting Specify 7. Each scenario is available in our member-exclusive [GitHub repository](https://github.com/specify/docker-compositions/) in both `docker/` and `podman/` directories. > [!note] Contact Us > [**📨 Click here to request access**](mailto:support@specifysoftware.org?subject=Requesting%20Docker%20Repository%20Access&body=My%20GitHub%20username%20is%3A%20%0D%0AMy%20Specify%20Member%20Institution%20is%3A%20%0D%0AAdditional%20Questions%20or%20Notes%3A%20), including your GitHub username, member institution, collection, and any additional questions or notes you have for us. Clone the repo, pick the directory matching your needs (in either `docker/` or `podman/`), adjust environment variables, then start the containers using `docker-compose up -d` or `podman-compose up -d`. * * * ### 1. All-in-One **Use case:** Single-host evaluation or small to medium deployments where you want every service bundled: database, Specify 7, asset server, report runner, and web server. You can customize this configuration by disabling services you don’t need (such as the report runner) rather than using a separate installation method. **Key steps:** 1. Database setup: 2. Configure `.env` or `docker-compose.yml`: 3. Launch: Reference: [docker/all-in-one/docker-compose.yml](https://github.com/specify/docker-compositions/blob/production/docker/all-in-one/docker-compose.yml) or [podman/all-in-one/docker-compose.yml](https://github.com/specify/docker-compositions/blob/production/podman/all-in-one/docker-compose.yml) * * * ### 2. Specify Cloud **Use case:** Multi-instance hosting on a shared infrastructure where one host serves many Specify 7 deployments with templated configuration and centralized reverse proxy management. **Key steps:** 1. Prepare prerequisites: 2. Configure template inputs in `docker/specifycloud/` or `podman/specifycloud/`: 3. Generate runtime configuration: 4. Launch: Reference: [docker/specifycloud/README.md](https://github.com/specify/docker-compositions/blob/production/docker/specifycloud/README.md), [docker/specifycloud/docker-compose-template.yml](https://github.com/specify/docker-compositions/blob/production/docker/specifycloud/docker-compose-template.yml), [podman/specifycloud/README.md](https://github.com/specify/docker-compositions/blob/production/podman/specifycloud/README.md), or [podman/specifycloud/docker-compose-template.yml](https://github.com/specify/docker-compositions/blob/production/podman/specifycloud/docker-compose-template.yml) * * * ## Updating Specify 7 > [@How to Update Specify 7](https://speciforum.org/t/how-to-update-specify-7/2475): > > [!note] Before You Begin Consider that the Specify Collections Consortium (SCC) offers the Specify Cloud hosting service to members of the consortium. By choosing SCC’s Specify Cloud hosting, you get a fully managed Specify 7 environment with automatic updates, priority support, and low-latency servers in cloud regions around the world. Daily backups of your database and attachments ensure your data is always protected. If you’d like pricing details, please see our [services prices](https://speciforum.org/t/specify-membership-and-technical-support-services-prices/2601) or get in t… ## Secure a Self-Hosted Specify 7 Environment > [@How to Secure a Self-Hosted Specify 7 Environment](https://speciforum.org/t/how-to-secure-a-self-hosted-specify-7-environment/3665): > > gear This guide provides a practical security baseline for institutions managing an internet-accessible production deployment. It covers host security, TLS/HTTPS, Django security settings, and ongoing operations. Recommended Background Reading [Self-Hosting Specify 7](https://speciforum.org/t/self-hosting-specify-7/2591)[Specify 7 Architecture Overview](https://speciforum.org/t/specify-7-architecture-overview/2590)Step 1: Harden the Host Make sure to configure a firewall before exposing Specify to the public internet. Apply all outstanding operating system updates and reboot if required. Disable passwo… ---
**Author:** ![Grant](https://yyz1.discourse-cdn.com/flex029/user_avatar/speciforum.org/grant/32/4255_2.png) [@Grant](https://speciforum.org/u/Grant)\ **Post date:** [April 1, 2026, 1:45pm UTC](https://speciforum.org/t/self-hosting-specify-7/2591/2 "2026-04-01T13:45:46Z")