Search the Community

Once a ProcessWire site is live, the production database is not a deployable artifact. It is the source of truth for content, users, roles, module settings, and module-owned data. Deploy code from Git. Apply reviewed migrations to the production database. Preserve production data, uploads, configuration, and secrets. If an AI coding agent is involved, write these boundaries down in AGENTS.md and enforce them with scripts rather than relying on the agent to infer what “deploy” means. I arrived at this rule through a real incident. The incident I was rebuilding a ProcessWire site locally with an AI coding agent. The data model had changed substantially, the development site contained useful demo content, and the production site had little activity. I asked the agent to deploy the new version and replace the old data. Technically, the operation succeeded: the code was deployed; the new schema appeared; the development database was imported; development uploads replaced production uploads; the public pages worked. But a database is not just “content”. The import also replaced production-only module configuration, users, roles, support tickets, AI conversations, and records stored in custom module tables. SMTP happened to survive because its configuration matched in both environments. Other settings did not. Backups existed, so the incident was recoverable. The site also had almost no real activity. On a busy site, the same operation could have destroyed orders, form submissions, member accounts, unpublished editorial work, audit history, or messages created during the deployment window. The important lesson was not “the AI made a mistake”. The deployment process allowed an ambiguous instruction to become a destructive database operation. That is a systems problem. Why ProcessWire needs an explicit deployment model ProcessWire's file layout is deliberately clear: /wire/ contains the core, while /site/ contains site-specific templates, modules, configuration, and assets. The official documentation also identifies site/config.php as the site configuration file and site/assets/ as writable runtime storage. That filesystem separation is useful, but a mature ProcessWire project has another boundary that is easier to miss: Deployment ownership map Git release — templates, hooks, module code, and frontend assets. Source of truth: the repository. Database structure — fields, templates, fieldgroups, and module schemas. Source of truth: reviewed migrations. Production database — pages, users, roles, settings, submissions, and module-owned tables. Source of truth: production. Runtime configuration — database credentials, hostnames, and environment flags. Source of truth: the production runtime. Secrets — SMTP, API, and OIDC credentials. Source of truth: a secret store or protected runtime files. Writable assets — uploads, generated files, logs, sessions, and backups. Source of truth: production storage. The initial launch is special. If production is empty, cloning a reviewed development database may be reasonable. After the first real user, form submission, editor change, or module configuration, that direction must stop. Production may flow to development through a protected and preferably sanitized snapshot. Development must not flow back as a whole database. This is the same problem described in ProcessWire's own article introducing migrations: once the live server receives content while features continue to be developed locally, the databases diverge and changes must be merged rather than replaced. Use releases for code and migrations for change A production release should be an immutable Git commit, preferably accompanied by a tag. Build the deployable file list from that commit—not from the current working directory. A release manifest should include only public runtime code and static assets. It should explicitly exclude: .git/ and CI configuration; AGENTS.md and development documentation; site/config.php and environment-specific config; database dumps, credentials, and private keys; site/assets/files, caches, logs, sessions, and backups; tests, fixtures, local tooling, and editor configuration. ProcessWire fields and templates live in the database, so code deployment alone is not always sufficient. Represent structural changes as idempotent, versioned migrations. A migration may use ProcessWire's API, a migration module, or a project-specific CLI script. The important properties are the same: it has a preview or audit mode; it is safe to run more than once; it changes only named structures or records; it preserves unknown production configuration; large transformations are bounded and resumable; destructive steps require a fresh verified backup and rollback data; successful application is recorded. ProcessWire has community options such as ProcessDbMigrate and migration modules, but no tool removes the need to classify production data correctly. A backup is not verified until it can be restored “The backup command returned zero” is not enough. For every production release: create a timestamped database backup outside the document root; verify its size and checksum; verify compressed-stream integrity; periodically restore it into an isolated database; keep a backup of the exact files being replaced; record the rollback path before changing production. This matters because backup tools can produce syntactically valid-looking files that fail only during restoration. Test the recovery path, not merely the backup button. The official ProcessWire upgrade guide likewise recommends backing up both files and database and testing upgrades on a development or staging site first. Add a fail-closed deployment guard Documentation is necessary, but an executable invariant is better. Before deployment, create a private snapshot containing no secret values: row counts for protected tables; page counts by template; stable page IDs by template; installed module names; names and configured/empty state of module configuration keys; intended Git commit; production hostname; verified backup metadata. After code deployment and migrations, take the same measurements and compare them. Block completion if: a protected table disappeared or lost rows; a pre-existing page ID disappeared; a template or installed module disappeared; a module configuration key disappeared; a configured value became empty; the host or release commit does not match. Stable IDs matter. Row counts alone can miss a replacement database containing the same number of different records. Some legitimate migrations intentionally remove obsolete data. That should be an exceptional workflow requiring a change ID, a table-by-table impact report, a tested restore, and a second explicit approval. A generic “deploy everything” instruction must never authorize it. What to tell an AI coding agent An AI agent is fast enough to turn an ambiguous sentence into a complete deployment before a human notices the ambiguity. Give it a narrower contract. The repository instructions should state: development and production paths and hostnames; production is read-only unless a production change is explicitly requested; commit, push, deploy, migrate, publish, and replace data are separate actions; “deploy” means code-only unless named migrations are included; a development database must never overwrite a launched production database; production users, content, module configuration, custom tables, and uploads must be preserved; secrets must not be read, printed, hashed, copied locally, or committed; every mutation needs a fresh verified backup and exact rollback path; migrations run in preview first and must be bounded/idempotent; a data decrease is a blocker, not a warning; if scope is ambiguous, stop after read-only investigation; destructive approval is two-phase: impact report first, explicit confirmation of that report second; maintenance is not removed and success is not reported while checks fail. The open AGENTS.md format is useful here because it gives multiple coding agents a predictable repository-level instruction file. Its documentation explicitly recommends including build commands, testing, security concerns, and deployment details, and supports more specific nested files where needed. I prepared a reusable template and attached it to this post as ProcessWire-AGENTS-production-safety-template.zip. The archive contains a single AGENTS.md file. Download it, replace the placeholders, and commit it to the root of your project. Do not deploy it into the public document root. A practical release checklist Before maintenance Select an immutable Git commit. Review the diff and release manifest. List every migration and classify its risk. Create and verify database and file backups. Create the protected data snapshot. Write the rollback command/path. During maintenance Deploy only manifest files. Preserve production config, secrets, uploads, logs, sessions, and backups. Run migrations in preview, then apply. Run the fail-closed comparison. Stop on any unexplained decrease. Before reopening Test origin and CDN routes. Test authentication and representative member workflows. Verify email delivery readiness and background jobs. Inspect new logs without exposing secrets. Record commit, manifest checksum, migration results, backups, and rollback. Remove maintenance only when every blocker is resolved. Final principle The database is not “the backend version of the code”. On a live ProcessWire site it is accumulated production state. AI does not change this rule. AI makes it more important to encode the rule in files, scripts, permissions, and fail-closed checks—because the agent can execute a bad assumption much faster than a human can recognize it. References ProcessWire file and directory structure ProcessWire: migrating to production ProcessWire upgrade best practices ProcessWire file permissions and protecting site/config.php ProcessWire: Introduction to the Migrations module ProcessDbMigrate module directory entry AGENTS.md open format ProcessWire-AGENTS-production-safety-template.zip

Hey folks, Quick question, is there anything you usually do to the database before pushing a project to a live server? Any kind of cleanup, optimization, that sort of thing? The reason I'm asking is that during development it's pretty common to install/uninstall modules, add and remove fields, rename things, test content... and after all that back and forth I'm a bit worried about leftovers sitting in the database that I might not even be aware of. Orphaned fields, stale module data, log entries, sessions, you name it. Do you have a checklist you follow? Any specific things you always make sure to clean up? Cheers.

Hi, I'm a System Administrator responsible for DevOps in our Company. We're trying PW in a single client project atm and experience some glitches with DevOps-/Workflow. We have a small team of developers that need to work with the same code base. They all need to be able to develop locally and deploy to a preview/staging environment. Our Toolstack contains git for versioning, chef/vagrant or docker for local development/testing and Jenkins for building assets and automatic deployment to the staging-site. There's several challenges / glitches in this process that makes me think that ProcessWire hadn't been developed for a use case like ours and is much more intended to be used by single developers that work right on the production system. Can you advise me on a suitable workflow? There's problems with the assets/files dir that must be shared between the staging website and local environments of our developers. We're right now working with symlinks on the staging system that helps to preserve the direcory when deploying from the master branch. but now we tend to use nfs-shares so devs can collaborate with a shared directory. The local docker containers can use the same target (the nfs) from inside the containers. But is that the way it needs to be done? Really? There's so much work that needs to be done to fit ProcessWire in a DevOps Workflow that we tend to decide to switch to another CMS. Any suggestions or hints that i might have missed. Am I wrong or is PW really not meant to be used this way. I

hi, do you guys use some special deployment tools or do use interesting workflows for deployment you like to talk about? actually i do it the olfd fashioned way: i'm developing on a local xampp and when i'm finished i upload the ftp-data to the webspace and import the database manualy with phpmyadmin. but i like to evolve my workflow to a more flexibel deployment process. for instance it woud be nice to develope on my local xampp but to be able to syncronize to a dev.cooldomain.com website all my ftp and mysql data with a button click. i also like the idea to syncronize with an php-tool between two seperate folders and database on the webserver the live and the dev. version of a site, to test new things and show them to people etc.

Hi, I've recently started on a team using Processwire, so Im quite new to it but I've had plenty of experience with Symfony2. We have an agency licence for the FormBuilder module and we want to use some sort of CI to deploy. When you first install FormBuilder module, it creates some new tables and requires some set up via a GUI including adding a licence key. We have looked into containing our licence key in a config file, then using some JSON files to sync to the database. This doesn't give us a lot of control and requires a fair bit of custom migrations. Is there a way to deploy a ProcessWire site including the FormBuilder module without going through the GUI setup every time? If not, Are there any migration modules for ProcessWire? If not, are there any recommended third party migration tools that are frequently used with ProcessWire? Many thanks!

Hi, I have deployed a PW 2.4 site to a shared domain as an addon domain. The URL is http://www.upasana.ca. I have run into the following issues: 1. If I use the .htaccess file that ships with PW 2.4 I get an "Internal Server Error". I have PW 2.3 sites as addons and they are working. If I copy the .htaccess file from PW 2.3 the site appears to work. The main site is a PW 2.3 site so I don't know if there is a conflict between the addon domain having PW 2.4. 2. I am getting an unstyled login and admin system. I think this might be permissions. When I check the permissions for the /wire folders they are 755 and files are 600. I do not know if the files should be 644 but I don't want to mess with the wire folders unless I know what is supposed to be there. Thanks, Anthony

Hello, I've been user Processwire for the first time and absolutely love it. I had used MODX before and this is so much better. But I am getting a little stuck when it comes to uploading my local MAMP site to the live server. This is what I have done so far. Created new Database on live server, exported database from local, and imported to the new db in live. Changed settings in /site/config.php with new database and user details. But while I'm on this, my config.php file has 2 areas to edit all the database details, is this normal? FTP'd all files over to the live server via FileZilla. When I load up the domain (web.johnhalsey.co.uk) I get an error. 500 Internal error. I have tried putting debug mode to true in the config file but it doesn't change the error. Have I missed something blatantly obvious (its very possible). Any help is appreciated, Thanks

Just saw (via Gertrud Schrenk) that BitNami (Company that packages popular open source apps into easy to install images in various formats, including AWS cloud images) is having a contest for which apps to include next as a package, where you can vote for ProcessWire. To quote the site: Please, all go and vote for PW at: bitnami.com/contest ! Cheers