Guided docking-box setup
The app helps users define and save docking centers from a browser workflow instead of relying on loose notes, screenshots, or manual coordinate copying.
Docking preparation should be reproducible, transparent, and easier to hand off.
Molecular docking is powerful, but the preparation work around it is often repetitive: renaming receptor files, tracking docking-box coordinates, cleaning structures, converting formats, organizing ligand libraries, and assembling run folders over and over again. AutoDock-Vina PrepServer was built to make that setup clearer, faster, and easier to reproduce.
The problem
Docking workflows often fail before docking even starts.
Many docking projects depend on a fragile chain of small setup decisions: which receptor file was used, which heteroatoms were removed, where the docking box was centered, which ligand file contained the final molecules, and which folder actually holds the runnable inputs. These steps are not scientifically glamorous, but they decide whether a docking run is repeatable.
For students, shared lab users, collaborators, and teams moving between local computers and HPC environments, the same setup problems repeat: inconsistent file names, lost coordinates, incomplete receptor conversion, unclear ligand mapping, and hand-built directories that are hard to audit later.
Common pain points
Manual docking preparation can create avoidable errors: copied coordinates, missing PDBQT files, inconsistent ligand identifiers, unclear cleanup choices, and run folders that only one person knows how to reproduce.
Structured receptor preparation
Receptor intake, cleanup choices, and receptor conversion are organized into a staged workflow so users can see what has been uploaded, centered, prepared, and packaged.
Ligand intake with column awareness
Ligand inputs can come from SDF, SMILES, SMI, CSV, ZIP, or folder uploads where enabled. CSV workflows preserve an explicit SMILES-column selection before package generation.
Downloadable job packages
The result is a ZIP package intended to be moved into a downstream docking environment, reducing the need to hand-build run directories from scratch.
Local and HPC-oriented use
The public mode focuses on portable packages. Deployments can also enable scheduler-oriented assets for teams that use LSF/HPC-style docking workflows.
Open-source research infrastructure
The project is designed as transparent scientific tooling, not a black-box docking claim. The source code is available at https://github.com/Joey305/autodock-WEBSERVER.
Who this is for
AutoDock-Vina PrepServer is intended for researchers, students, educators, computational chemistry groups, structural biology labs, and shared scientific teams that need a cleaner way to prepare docking inputs before running AutoDock Vina or related downstream tools.
What it is not
PrepServer does not guarantee docking accuracy, replace receptor curation, replace medicinal chemistry review, or perform a closed-loop AI discovery process. It prepares transparent, inspectable files so scientists can run and evaluate docking workflows more consistently.
How it fits
A focused preparation layer, not a replacement for docking review.
PrepServer sits before downstream docking execution. It helps assemble the files and metadata that scientists usually collect manually: receptor structures, cleanup choices, docking box coordinates, ligand inputs, package mode, and generated instructions.
That focus is deliberate. It keeps preparation inspectable while leaving scoring, pose review, medicinal chemistry interpretation, and experimental relevance to the appropriate downstream tools and expert review.
Build a reproducible docking package.
Start with receptor files or a PDB ID, define docking centers, upload ligand inputs, and export a package for downstream AutoDock Vina execution.
FAQ
About the preparation approach
Why focus on docking preparation instead of docking execution?
Preparation is where many reproducibility problems begin. Keeping file intake, center selection, receptor conversion, ligand provenance, and package assembly visible makes downstream docking easier to audit.
Who should review generated packages?
A scientist familiar with the receptor system, ligand set, search-space choice, and downstream AutoDock Vina parameters should review generated files before using results for decisions.
Can teams adapt the server for private deployments?
Yes. The Flask application is open source and can be inspected or adapted, but private or regulated deployments still need appropriate authentication, storage, cleanup, and data-governance controls.