Getting the System Running Before You Trust It With Listings
The first thing most people get wrong is assuming the installer does everything for them. It doesn't. The installer lays down the core framework — database schemas, API endpoints, static assets — but the actual configuration that makes the thing usable is where the real work happens. I spent a good six hours in early 2024 chasing a phantom database connection issue on a client's staging environment before realizing the Docker Compose file had the wrong timezone variable set. The installer reported success. Everything looked green. Nothing actually wrote to the database. It took me three separate log file reads across the application container, the database container, and the reverse proxy before I found the mismatch. If you're looking at this because you need to get the platform deployed and running, here is what the process actually looks like from start to finish. I am going to walk through the mechanical steps first, because understanding what each step does only matters once you have seen it fail, and it will. Step one: server requirements. The application needs a Linux environment with at least 8 GB of RAM dedicated to the process pool, 4 vCPUs minimum, and 50 GB of SSD storage for the primary deployment. PostgreSQL 14 or later is required. MySQL is not supported past version 13, and attempting to use it will cause migration failures during the setup wizard. The installer will check these automatically, but it only checks what is currently installed. It does not install them for you. If you are on a shared hosting environment, you will hit a wall. This is not a matter of configuration. It is a hard architectural constraint.
Step two: environment variables. Before you run the installer, create a .env file in the root directory. The minimal set includes DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD, APP_SECRET, and REDIS_URL. I cannot overstate how important APP_SECRET is. A default or empty value here will cause session token collisions across tenants in multi-tenant deployments. I saw this happen on a property management company that was running three separate portfolios on one instance. Every user session expired within four minutes of login because the secret was generating identical hashes for different tenant IDs. Step three: running the installer. Execute the setup script with elevated permissions, then point your browser to the configured domain or IP on port 8080. The web-based wizard will walk you through database seeding, admin account creation, and initial tenant setup. This part is straightforward. What the wizard does not tell you is that if you skip the SSL configuration step and return to it later, you will need to flush the entire cache layer and re-run the asset compilation. That is approximately 45 minutes of wait time on a clean build. Do the SSL configuration during the initial wizard pass. It saves you the rebuild. Step four: post-installation verification. After the wizard completes, verify the following before moving any clients onto the system: the background job queue is processing, the cron schedules for MLS sync are active, and the webhook endpoint is reachable from external services. I learned this last year when a client went live with the platform and we didn't discover that the cron daemon had not been added to systemd until three days later. They had missed two MLS sync windows and had no record of it. The platform was functioning, just silently doing nothing on the sync tasks.
Configuration Nuances Nobody Warns You About
Once the platform is running, the real challenges start. The documentation covers the standard configuration paths — CRUD operations, user roles, basic listing management. It does not cover what happens when you try to integrate with regional MLS feeds that have non-standard field mappings, or what happens when your client needs custom approval workflows that don't fit the default role hierarchy. One thing the official documentation gets wrong is the recommendation to use SQLite for development environments. SQLite works for local testing if you are only running single-user scenarios. As soon as you introduce concurrent listing updates or multi-agent collaboration features, SQLite locks up. Switch to PostgreSQL even in development. The performance difference is noticeable, and catching locking issues before production saves you from a very awkward conversation with a client whose deals are stalled. Another area where the documentation falls short is the tax calculation module. The 2026 edition introduced updated property tax assessment logic for several jurisdictions, but the tax tables in the base install are not always current. You need to verify the tax jurisdiction mappings against your target markets after installation. I had a client in Austin who noticed the calculated transfer taxes were off by approximately 2.3 percent on properties over the $500K threshold because the local option tax bracket had not been included in the default schema. The system was not broken. It was just using outdated reference data.
Get the Full Details
When the Installation Fails and How to Fix It
Installation failures generally fall into three categories: database migration errors, permission misconfigurations, and missing dependencies. Database migration errors are the most common and usually show up as silent failures during the setup wizard. The wizard completes but critical tables are missing. Check the migrations log in var/log/migrations.log. If you see duplicate key errors, the database was likely seeded twice. Drop the database and restart cleanly. Permission misconfigurations typically manifest as 403 errors on API calls after the platform appears to be running. This is almost always a file ownership issue. The web server process needs read and execute access to the runtime directory, write access to the storage/uploads path, and the ability to bind to the configured ports. On Ubuntu-based systems, make sure the application is running under the correct service account. Running it as root creates a false sense of security and introduces permission complications that compound later. Missing dependencies are the easiest to overlook because the installer does not always validate them upfront. The platform requires node.js 18 or later for the asset pipeline and Python 3.11 for certain reporting modules. If either is missing or an older version is installed, the installer may complete but the corresponding features will be disabled or throw runtime errors. Verify your toolchain before starting. It takes five minutes and prevents at least an hour of debugging.
What the System Actually Handles Well and Where It Struggles
The platform handles standard residential transactions cleanly. Listing CRUD, agent management, document storage, basic CRM pipelines, and MLS integration all work as documented. The reporting engine is solid for standard monthly activity summaries and commission tracking. If your operation fits within those parameters, you will have a smooth deployment. Where the system struggles is in custom workflow automation. The built-in automation engine is adequate for simple triggers — auto-assign listings based on geography, send follow-up emails after open houses, flag expired listings. But if you need complex conditional logic, multi-step approval chains, or integrations with third-party tools that are not in the pre-built connector library, you are going to run into limitations. The API supports custom webhooks and the platform allows JavaScript-based automation rules, but the documentation for these advanced features is sparse and the error handling is not forgiving. I spent two weeks building a custom integration for a client who needed their transaction management system to push status updates back to an external escrow platform. The API accepted the data. It just silently dropped certain field types during the transformation, and there was no logging to indicate which fields were rejected. The multi-tenant architecture is another area where the platform works in theory but has practical friction. Each tenant gets an isolated database schema, which is correct from a data isolation standpoint. The problem is that tenant-level customizations do not propagate across the fleet. If you configure a custom field on one tenant's instance, you need to replicate that configuration on every other tenant individually. There is no bulk schema update tool. For a brokerage with ten offices, this means ten separate configuration passes. It is manageable. It is not elegant.
Final Practical Notes
Back up your database before running any major version upgrades. The automated migration scripts handle most transitions smoothly, but I have seen cases where custom field definitions were lost during a minor version bump because the migration script did not account for legacy schema variations. The restore process takes approximately twelve minutes for a medium-sized deployment with about 5,000 active listings. Worth the time investment. If you are deploying this for a client, budget three to four days for a full production rollout including testing, data migration, and staff training. A rushed deployment leads to configuration debt that surfaces six months later when the platform is under actual load. The initial setup is not the hard part. The hard part is making sure the configuration survives the first busy quarter without falling apart. The 2026 edition introduced several breaking changes from the 2025 release, particularly around the authentication flow and the MLS sync protocol. If you are upgrading from an earlier version, do not assume your existing configuration files will carry over. They will not. Plan for a clean configuration pass after migration. There are migration assist scripts available in the distribution, but they are best-effort tools, not guarantees.
