nf-core: Proteinfold
Necessary Disclaimers and Legal
The user is responsible for reviewing and complying with the license requirements of the software, models, and reference databases referenced in this documentation.
nf-core/proteinfold v2.0.0 supports multiple structure prediction modes, including AlphaFold2, ColabFold, ESMFold, Boltz, AlphaFold3, HelixFold3, RoseTTAFold-All-Atom, and RoseTTAFold2NA, each governed by independent license terms set by the respective third-party developers. Before use in any commercial or for-profit context, users must independently verify current license terms directly from the original developer's source. In particular:
Commercial use may be restricted at the level of model weights, reference databases, or both, even where the source code itself is permissively licensed
License terms may change over time at the developer's discretion
Prediction Model
Code License
Weight License
Commercial?
Note:
The 2021-07-14 AlphaFold parameters are released under the CC BY-NC 4.0 license, which restricts their use to non-commercial purposes only. We recommend using the alphafold_params_2022-12-06 release instead, which is licensed under CC BY 4.0 (permitting commercial use with attribution) and contains the same monomer/pTM weights as the 2021 release.
Some model weights and databases referenced in the nf-core/proteinfold configuration (e.g., PDB100, HelixFold3, RoseTTAFold) are subject to non-commercial or restricted-use licenses; we did not download these components, and we recommend users verify the applicable license terms before use.
Users are responsible for the costs associated with nf-core/proteinfold, protein structure prediction methods, databases, and their storage in their project spaces.
Instance type availability and pricing are subject to the contract between the user or the user's organization and DNAnexus.
Citation for nf-core/proteinfold v2.0.0
nf-core is a community-driven collection of curated bioinformatics pipelines built using Nextflow, providing standardized, scalable, and portable workflows for reproducible analysis across diverse computing environments. Following these standards, nf-core/proteinfold enables state-of-the-art protein structure prediction through optimized Nextflow execution. If you use nf-core/proteinfold, please cite the pipeline accordingly. Additional references for integrated tools are listed in the pipeline’s CITATIONS.md.
Overview of nf-core/proteinfold v2.0.0 pipeline
Version 2.0.0 (released on March 27, 2026) is a major release that significantly expands the pipeline compared to v1.1.1, which supported three prediction modes (AlphaFold2, ColabFold, and ESMFold). The new version introduces several key additions and changes:
5 new prediction modes: Boltz, AlphaFold3, HelixFold3, RoseTTAFold-All-Atom, and RoseTTAFold2NA, bringing the total to 8 modes.
Of these 8 modes, only AlphaFold2, ColabFold, ESMFold, and Boltz are free for commercial use based on the current licensing of their code, weights, and required reference databases.
Multi-mode parallel execution: multiple modes can now be run simultaneously using a comma-separated list (e.g. --mode alphafold2,colabfold,boltz)
Sample sheet schema: the input column was renamed from sequence to id.
The pipeline produces an interactive HTML report to visualize structure prediction outputs.
Version 2 supports an optional Foldseek easy-search step on the top-ranked structure per input/mode combination, but this step is disabled by default (skip_foldseek = true) and is not part of core structure prediction functionality. Foldseek has not been deployed on this DNAnexus platform because of its restricted license.
On DNAnexus, we have made the nf-core/proteinfold (version 2.0.0) directly available, together with a CSV Builder for preparing inputs and a full database ( > 4 TB). See the “Where to Access nf-core/proteinfold v2.0.0” section below to start accessing the dataset and the applet.
Where to access nf-core/proteinfold v2.0.0
These files are found on the platform here for AWS US East, here for AWS Europe (Frankfurt), here for AWS Europe (London), here for Azure Amsterdam, and here for Azure US (West).
The nf-core/proteinfold v2.0.0 folder on DNAnexus is organized as follows:
Note on project ID: Throughout this guide, replace project-xxx with your own DNAnexus project ID. Your project ID can be found on the DNAnexus platform under Project Settings, or by running dx CLI.
Note on parameter prefixes: Parameters prefixed with -i (e.g. -ioutdir, -inextflow_run_opts) are DNAnexus applet input arguments passed to dx run. Parameters prefixed with -- (e.g. --genome, --fasta) are Nextflow pipeline parameters, typically supplied via a JSON params file or within nextflow_run_opts.
Copying applet and data into a project
To use these resources, you have two options:
Option 1: Clone the datasets and applet into your own DNAnexus project. Follow the steps below.
Option 2: Reference the databases directly from the Public Datasets project, without copying. Our example uses AWS US (East), but the Public Datasets are also available in other regions.
Steps to copy data into your own project:
Create a new project billed to your organization. See Setting Up a Project for instructions.
Go to the Resources tab and find the project "Public Datasets AWS US East". Navigate to the ProteinFold_v2.0.0 folder.
Select the folders and files you need.
Click Copy from the top right menu and select the project you created in Step 1.
Go to your project to start running the pipeline.
Note: The example_results/ folder contains output from completed pipeline runs and is provided for reference only.
Samplesheet input
The samplesheet is a .csv file passed to the pipeline via --input. Each row represents one protein sequence to be folded/predicted. There are two required columns: id and fasta.
Each FASTA file should ideally contain only a single protein sequence, unless you are running in multimer mode. If you need to fold multiple sequences individually, you can supply one or more FASTA files containing several sequences using the --split_fasta parameter. In this case, the pipeline treats every sequence within the file as its own independent entry, folding each one separately and in parallel.
Using the CSV Builder to prepare your samplesheet
Instead of manually writing the samplesheet, you can use the CSV Builder for nf-core/proteinfold, an applet on DNAnexus platform that generates a pipeline-ready samplesheet. It validates your input against the correct schema (id,fasta for v2.0.0), automatically resolves file paths into dx:// URIs, and saves the output directly to your project.
Quick steps:
Copy the proteinfold_samplesheet_builder applet and example dataset into your project (see [CSV Builder User Guide <LINK>] for setup instructions).
Launch the applet from the DNAnexus platform.
Provide your input using either:
fasta: select one or more FASTA files directly from your project, or
prefilled samplesheet: upload an existing .csv file with sequence names and file references.
Select the ProteinFold pipeline version 2.0.0.
Set an output samplesheet name and destination, then launch the job.
The job typically completes in ~2 minutes. Once done, verify the job status is Done and the output .csv matches the expected schema for version 2.0.0. For detailed setup, input formats, and troubleshooting, refer to the full CSV Builder for nf-core/proteinfold user guide <LINK>.
Example samplesheets
Several example samplesheets are provided in the example_samplesheet_files/ folder on the platform.
Most of these samplesheets reference FASTA files hosted on the nf-core/test-datasets GitHub repository and are downloaded directly at runtime. These can be used as-is without modifying any paths, making them a convenient option for quickly testing the pipeline.
proteinfold_v2.0.0_samplesheet_dx_path.csv is an example samplesheet showing dx:// paths pointing to files staged on the platform (Public Dataset AWS East project, project-J3JyY6j030gzQypGpk273241). This is an example output generated by the CSV Builder.
Databases
nf-core/proteinfold relies on external reference databases and model parameters to run its supported prediction modes. They are pre-downloaded and arranged on the DNAnexus platform to match the exact structure nf-core/proteinfold expects, so you can skip the download step entirely and point straight to --db parameter, saving significant setup time.
The reference databases for this project are organized as follows:
Each mode utilizes a subset of these folders, as detailed in the table below. When running the pipeline, you can use the --db parameter to specify a single parent folder (e.g., db/) instead of defining each folder path individually.
Folder
Used by
bfd
AlphaFold2
small_bfd
AlphaFold2
uniref90
AlphaFold2
uniref30
AlphaFold2
mgnify
AlphaFold2
pdb70
AlphaFold2 (monomer templates)
pdb_mmcif
AlphaFold2
pdb_seqres
AlphaFold2
uniprot
AlphaFold2
colabfold_uniref30
ColabFold (local search mode)
colabfold_envdb
ColabFold (local search mode)
params
All modes (model weights/parameters)
For detailed per-mode file structure, refer to the official usage docs: AlphaFold2, ColabFold, ESMFold, Boltz.
Notes:
Each database folder needs to keep its internal file names and layout exactly as downloaded. For example, bfd/ must contain:
Do not rename or move files inside them unless you have verified the pipeline's expected structure for that specific folder.
Running the pipeline
Resource configuration
Depending on your samples, selected modes, and databases, you may need to adjust compute resources (instance type, memory, CPU, GPU). A single soft config file, all_models_gpu_dnanexus_real_db.config, provides example resource settings for all modes.
This file is provided using the input parameter -inextflow_soft_confs. When a process defined in the soft config file is run, an appropriate machine satisfying all requirements is requested. It also sets a global docker.runOptions rule to run the process on a GPU, if GPU mode is chosen.
Example resource settings
Note: ESMFold includes a beforeScript that fixes a CUDA library path issue when running on Seqera Platform (Tower). This only activates when the TOWER_WORKFLOW_ID environment variable is present.
Quick Start Test
Use ESMFold mode to quickly validate the pipeline and applet setup (~46 minutes).
Run via UI
Navigate to your ProteinFold_v2.0.0 folder and click on the proteinfold_v2.0.0 applet, then Run.
Provide a Job Name (e.g., proteinfold_2.0.0_esmfold_test) and choose an output destination.
Under the INPUTS tab, click the input box (labeled "Select File").
In the file browser that opens, navigate to example_samplesheet_files/ (or your own samplesheet location) and select your samplesheet CSV (e.g., samplesheet.csv). Click Select.
Click the nextflow_soft_confs box (labeled "Select File").
In the file browser that opens, navigate to soft_configs/ and select all_models_gpu_dnanexus_real_db.config. Click Select.
Under the COMMON section, fill in the following:
Enter the output directory name (e.g., esmfold_monomer) in the outdir box. The pipeline will create a folder with this name inside the destination folder to save all output files.
In the mode box, type the model you want to use, such as esmfold. Mode can be any combination of alphafold2, alphafold3, colabfold, esmfold, rosettafold_all_atom, boltz, helixfold3, rosettafold2na separated by a comma (,) with no spaces.
Set use_gpu to True to run on a GPU instance.
In the db box, enter the path to the reference database: dx://project-xxx:/ProteinFold_v2.0.0/references/db/ and set True for full_dbs.
Scroll down to the model parameter section. In the esmfold_model_preset box, type monomer for this run (leave esmfold_num_recycles as default unless needed).
8. Under the NEXTFLOW OPTIONS section, enter -profile docker in the Nextflow Run Options box.
9. Click Start Analysis to launch the pipeline.
10. Go to the MONITOR tab to check the pipeline execution progress. The Inputs and Outputs section at the bottom summarizes all input parameters and the output files from the run.
Run via command line
AlphaFold2
By default, the pipeline splits MSA generation from model inference for more efficient resource use. The example below runs AlphaFold2 in standard mode using the default monomer_ptm preset, with the full BFD database. Please note that the runtime is nearly 5 hours.
There are two ways to submit this run: using a parameter JSON file, or passing all inputs directly via dx run. An example parameter JSON file for this run is available at example_parameter_files/alphafold2_parameters.json.
Option 1: Using a parameter JSON file
Once the JSON file is saved on the platform, submit the pipeline using dx run:
Option 2: Passing all inputs directly via dx run
Boltz
By default, Boltz uses a local ColabFold search protocol (MMseqs2) to generate MSAs based on the Boltz usage documentation. This requires both colabfold_db and boltz_db to point to the reference database. This example is adapted from nf-core/proteinfold's test_full_boltz.config, using the full reference database on this platform instead of the mini test databases, and all_models_gpu_dnanexus_real_db.config for resource allocation.
Please note that the runtime is nearly 4 hours.
Output structure
After a successful run, results are saved to the folder defined by outdir in your parameters. The top-level structure varies by mode, but generally follows this pattern:
AlphaFold2 (standard, monomer):
Boltz:
In our example run, Boltz includes two extra folders: mmseqs/ (intermediate MSA search output from the local ColabFold search step) and split/ (per-sequence split files from SPLIT_MSA).
Example Results
We provide example results from completed pipeline runs, available for reference. For a quick view, you can access reports/, containing the interactive HTML report generated by GENERATE_REPORT, used to visualize the predicted structure(s).
Opening T1026_boltz_report.html shows a 3D structure viewer color coded by per residue confidence (pLDDT), where blue and cyan indicate reliable regions and yellow and orange indicate less reliable ones.
The report includes key visualizations such as sequence coverage, predicted Local Distance Difference Test (pLDDT), and Predicted Aligned Error (PAE).
Please refer to the official nf-core documentation for output explanation.
Technical considerations
outdir parameter
The outdir parameter is required and defines the subdirectory where results are stored. When launching the pipeline, choose a parent directory (e.g., results) and specify the desired output folder name (e.g., proteinfold_2.0.0_esmfold_test) in the outdir field.
Note: You do not need to manually create the proteinfold_2.0.0_esmfold_test folder inside results. The pipeline will automatically create it.
Modifications to the reference database structure
Several folders in the reference database were packaged into single .tar/.tar.gz archives instead of individual files, to avoid long staging times when transferring large numbers of files from platform storage into the job worker at runtime. These archives are extracted automatically during the pipeline run, so no manual extraction is needed beforehand.
pdb_mmcif/mmcif_files/mmCIF.tar.gz: the original structure expects individual, uncompressed .cif files. Since this folder contains 188,000+ files, the team packaged them into a single archive to stage as one file instead.
params/mols/mols.tar: the mols reference data used by Boltz contains 44,000+ individual files, packaged into a single archive inside the mols/ folder. This one is handled inside the RUN_BOLTZ process itself, which locates and extracts the .tar file in place before prediction runs.
db vs. mode-specific database parameters
You can point the pipeline to your database in two ways:
db: a single, general path that works for any mode.
<mode>_db (e.g. esmfold_db, alphafold2_db, boltz_db): a path specific to one mode.
If you only set db, the pipeline automatically applies it to the mode you're running. For example, running --mode esmfold with -idb alone is enough. You do not need to also set -iesmfold_db.
If you run more than one mode at once (e.g. --mode alphafold2,boltz), db is applied to both modes automatically.
Testing with the Built-in Test Profiles
nf-core/proteinfold provides test_full_* config profiles (e.g. test_full_boltz, test_full_alphafold2_multimer, test_full_esmfold) to verify the pipeline works correctly against a small mini reference database. We have not pre-downloaded this mini database on the platform. Running these test jobs stages it directly from its source (S3) at runtime.
To run a test profile, add it to -profile alongside docker (e.g. -profile test_full_alphafold2_multimer,docker), and pass our soft config file via -inextflow_soft_confs as usual:
Note: no -iinput, -imode, or -idb is needed. These are already defined by the test_full_alphafold2_multimer profile itself.
Boltz test profile: mols folder staging failure
The default test_full_boltz profile stages boltz2_mols_path from the S3-hosted mini database (s3://proteinfold-dataset/test-data/mini_dbs/params/mols/). This folder contains 45,000+ individual files. Staging this many small files as a foreign S3 file directly into a DNAnexus job repeatedly failed with chunk upload errors:
Therefore, we need to override boltz2_mols_path to point to a mols.tar archive staged on the platform, instead of the default mini database path:
Here is the command for the test_full_boltz profile:
Note: no -iinput, -imode, or -idb is needed, these are already defined by the test_full_boltz profile itself.
Last updated