Transparent docking-preparation infrastructure for researchers and developers.
AutoDock-Vina PrepServer is developed as an open-source web application for preparing molecular docking packages. The goal is to make docking setup easier to inspect, extend, and deploy across research environments.
What developers can inspect or extend
The open-source Flask repository exposes public templates, API routes, packaging helpers, tests, and deployment settings so developers can review how the docking preparation workflow is assembled and add documentation, validation, route tests, or deployment guidance.
Project structure
Built to keep preparation logic inspectable.
The public pages, browser workflow, API endpoints, packaging helpers, and tests live in a conventional Flask repository so future contributors can add documentation pages, reusable SVG sections, route tests, or deployment notes without turning the site into a monolith.
The project is best understood as research infrastructure: a focused tool for assembling docking-preparation assets, not a guarantee of downstream docking accuracy or a substitute for scientific review.
Built with Flask
The application uses Flask routes, templates, API endpoints, and packaging helpers to convert browser workflow steps into downloadable docking packages.
For scientists
Researchers can use the public web interface to prepare docking package inputs without manually assembling every folder, script, and coordinate file.
For developers
Developers can inspect the source, adapt deployment settings, add routes, improve templates, or extend the headless API for scripted workflows.
Extension areas
Good contribution targets include template content, route-level tests, API examples, deployment notes, input validation, cleanup policies, and accessible SVG explanations.
Deployment responsibilities
Operators should review authentication, public/private data boundaries, temporary storage cleanup, conversion dependencies, logging, quotas, and user communication before opening an instance.
Useful issue reports
Include the route or page, input type, package mode, concise error text, dependency versions where relevant, and whether the problem happens in browser or API workflows.
Documentation growth
New public pages should be routed, linked from the documentation hub or related-page partials, given page-specific metadata, and written with careful scientific claims.
Responsible use
Public deployments should be treated as public tools. Do not upload confidential receptor structures, proprietary ligand libraries, or sensitive project data unless the instance is explicitly configured and governed for that use.
FAQ
Open-source and deployment FAQ
Can I fork the repository for a private lab deployment?
The source is available for inspection and adaptation. A private deployment still needs appropriate security, access control, cleanup, and data-governance decisions before handling sensitive structures or ligands.
What kinds of changes are safest for new contributors?
Documentation improvements, template refinements, route tests, API examples, accessible visuals, and clearer troubleshooting content are useful low-risk contributions when they preserve existing workflow behavior.
Does open source mean public uploads are safe for confidential data?
No. Public deployments should be treated as public tools unless the specific instance is configured and governed for confidential use.