# Top Local Bioinformatics Software for Sensitive Data By the end of this guide, you will be able to set up a local bioinformatics environment where restricted data never leaves your machine, run a complete [sequencing pipeline](/blog/guides/sequencing-pipeline) step by step, self-host a browser-based analysis platform on your own hardware, and put practical safeguards around patient-derived or otherwise confidential datasets. To follow along you need a computer running Linux, macOS, or Windows with WSL2 (Windows Subsystem for Linux, a compatibility layer that runs a real Linux environment on Windows), administrator rights to install software, and your own data files such as FASTQ sequence reads or tabular omics results. The core argument is simple. Many bioinformatics platforms are described in the literature as web-based, and their papers openly state that they remove the burden of local installation or large file uploads [1][2][3]. That convenience is a real benefit for public data. For restricted data, the same design becomes a liability, because analysis requires transferring the dataset to somebody else's server. A small but growing set of tools takes the opposite approach. Some run as desktop applications on your own machine [4], some install a web server locally so data stays on your disk [5], some ship as containers you deploy on your own infrastructure [6], and some are clinical pipelines designed to run inside the laboratory that generated the samples [7]. This article covers those options, a concrete bioinformatics tools comparison, and a build-it-yourself walkthrough. ## Why Sensitive Data Belongs on Your Own Hardware Sensitive bioinformatics data includes [human genome](/blog/guides/human-genome) sequences, single-cell profiles linked to clinical records, medical images tied to patient identifiers, and any dataset where a codebook mapping sample IDs to individuals exists somewhere. Whole-genome sequence data is inherently identifiable, and clinical metadata multiplies that risk. The research literature illustrates both sides of the tradeoff. On the convenience side, a fully automated web platform for ChIP-seq analysis, H3NGST, was designed so that researchers need no local installations, no programming skills, and no large file uploads, with the platform handling raw data retrieval, quality control, alignment, peak calling, and annotation from a browser [1]. A proteomics platform built on the cloud-native CHIMERYS search algorithm similarly consolidates raw-data-to-insight processing into managed cloud services, with the authors of that work noting that fragmented pipelines running on local hardware are costly to maintain and scale [3]. Those are legitimate engineering arguments for cloud architectures. On the privacy side, a prototype for integrating clinical and mitochondrial data in obesity research made a deliberate architectural choice. Its medical records, coded with ICD-10 classifications, and its electron microscopy images are persisted transactionally and anonymously on the client side using the IndexedDB browser storage API rather than on a remote server [8]. The design goal was anonymized persistence under the researcher's own control, with an interactive prompt framework for large language model interpretation layered on top. A different project, the SEED health atlas, handles the sensitivity problem from the data side by publishing only de-identified and aggregated electronic health record data [9]. De-identification and local processing are complementary strategies, and for most restricted datasets you will want both. There is also a regulatory reality in clinical settings. A tuberculosis genomics pipeline called tbtAMR was developed specifically so that [clinical microbiology](/knowledge/diagnostics/microbiology/clinical-microbiology-from-specimen-collection-to-pathogen-identification) laboratories could analyze Mycobacterium tuberculosis sequence data on site, infer lineage and antimicrobial resistance from FASTQ files or annotated VCF files, and produce clinical-report-ready output, with validation against phenotypic and genomic reference results and accreditation to ISO standards [7]. A laboratory that cannot ship patient sequences off site needs exactly this kind of locally executable, standards-accredited software. ## Four Deployment Models for Local Analysis ![Comparison of desktop apps, locally installed web servers, containers and self-hosted Git servers by where data sits and what each suits.](/article-images/illustrations/best-local-bioinformatics-software-sensitive-data-deployment-models.webp) "Local" does not mean one thing. Understanding the four common models helps you match software to your situation and is the foundation of any honest bioinformatics tools comparison. **1. Desktop applications.** The software installs like any other program and reads and writes files on your disk. Profiler, an open multi-omics platform covering data import, quality control, statistical testing, machine learning, [biomarker discovery](/knowledge/molecular-biology/biomarker-discovery), pathway enrichment, and survival modeling, is distributed both as a web platform deployed on high-performance computing and as a desktop version for local execution [4]. PELSA-Decipher, a tool for processing and interpreting ligand-protein interaction datasets from the peptide-centric local stability assay (PELSA), is likewise a downloadable application that handles raw data processing, visualization, and report generation on your own machine [10]. **2. Locally installed web servers.** The interface runs in your browser, but the server process runs on your own computer or an internal server, so the data path never crosses the internet. PeptideShaker Online works this way. Storage and processing happen through a Galaxy backend running SearchGUI, PeptideShaker, and moFF, while interaction with results happens through a locally installed web server, letting researchers process and interpret their own proteomics data without sending files to an external service [5]. **3. Containers on your infrastructure.** Docker bundles software with its dependencies so it runs identically anywhere you deploy it. An intensive care data platform described in the literature uses Docker to let clinicians deploy one or many clinical databases in local, cloud, or remote environments, pairing the databases with locally hosted analytics interfaces (Metabase and Superset) and a fine-tuned large language model that generates SQL queries from natural language requests [6]. The local option in that design is what matters for restricted records. **4. Self-hosted collaboration servers.** Version control is part of the analysis infrastructure, not just code storage. One academic implementation deployed a dedicated local server based on the Git ecosystem for managing bioinformatics and medical AI projects, providing repository management, secure access control, course management, and assignment submission, and the platform was used to develop a new bioinformatics software package end to end [11]. A note on hybrid options. R Shiny applications, which are interactive web interfaces written in R, are usually described as web-based platforms in the literature, as with the SimpleMicrobiome platform that integrates taxonomic profiling, diversity analysis, differential abundance testing with ANCOM-BC2 and MaAsLin2, [Random Forest](/blog/data-analysis/what-is-random-forest) modeling with SHAP interpretation, and network inference with SparCC and SPIEC-EASI [12]. Because Shiny runs on the R runtime, such an application can also be served from your own machine, which keeps the friendly interface and keeps the data local. The same logic applies to any platform that publishes its source code: if you can run it, you can host it. ## Bioinformatics Tools Comparison for Sensitive Data The table below summarizes the local-capable options discussed in this article and the role each one fills. | Tool or platform | What it does | Deployment model | Why it fits sensitive data | |--|--|--|--| | Galaxy (self-hosted) | Point-and-click workflow engine for NGS and proteomics | Local web server on your hardware | Data stays on your disk, provenance tracked | | Profiler | Multi-omics QC, statistics, machine learning, biomarker discovery, survival modeling [4] | Desktop version for local execution | Full analysis stack without cloud upload | | PeptideShaker Online | Proteomics identification, from raw file conversion to interactive visualization [5] | Galaxy backend plus locally installed web server | Processing and interpretation both local | | PELSA-Decipher | Processing and interpretation of PELSA thermal-shift proteomics data [10] | Downloadable desktop software | Binding proteins, sites, and affinities computed locally | | tbtAMR | Tuberculosis lineage calling and antimicrobial resistance prediction [7] | Command-line pipeline in the clinical lab | Built for accredited clinical reporting on site | | DREAM-Stellar | Sensitive exact local alignment of genomes [13] | Command-line, parallelized on your cores | High analytic sensitivity with bounded runtime | | ICU-GPT database stack | Docker-deployed clinical databases with Metabase, Superset, and LLM-generated SQL [6] | Containers on local, cloud, or remote hosts | Local option keeps records on your infrastructure | | Self-hosted Git server | Version control, secure access control, collaboration [11] | Dedicated internal server | Audit trail and access control for code and results | | Client-side browser apps | Data entry and persistence in browser storage [8] | HTML5 plus IndexedDB on the client | Anonymized records persist locally, not server-side | Two of these entries deserve a comment because they address a different meaning of "sensitive." In sequence analysis, sensitivity means the ability to find true matches rather than miss them. DREAM-Stellar, a parallelized rewrite of the Stellar pairwise local aligner, uses an inverted bloom filter (IBF, a compact data structure for set membership queries) as a prefilter and found that heuristic tools like BLAST miss a large percentage of significant local alignments or drown them in less significant matches. On 32 parallel threads it runs up to 900 times faster than its single-threaded predecessor while finding all alignments between a pair of genomes in minutes [13]. That combination of analytic sensitivity and bounded runtime on ordinary multicore hardware is precisely what a local workstation needs. Similarly, PELSA is a ligand modification-free method with unusual analytic sensitivity for detecting protein targets of drugs, antibodies, metabolites, and metal ions, and PELSA-Decipher packages the computational workflow including raw data processing, visualization, and report generation [14][10]. Choosing tools that are sensitive in the analytic sense and local in the data sense gives you both meanings of the keyword. ## Step-by-Step: Building a Local Analysis Workstation This walkthrough uses the conda package manager, the de facto standard for installing bioinformatics software with isolated environments, and builds a small sequencing pipeline. Every command shown is standard usage documented by the tool itself. ### Step 1. Install Miniconda Miniconda is the minimal installer for conda. On Linux x86_64: ```bash wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3 $HOME/miniconda3/bin/conda init bash source ~/.bashrc ``` The `-b` flag runs the installer in batch mode so it does not prompt interactively, and `-p` sets the install directory. On an Apple Silicon Mac, download the matching installer from the same location and substitute the correct file name. ### Step 2. Create an isolated environment ```bash conda create -n clinseq -c conda-forge -c bioconda \ python=3.11 fastp bwa samtools bcftools conda activate clinseq ``` Here `-n clinseq` names the environment, `-c bioconda` adds the Bioconda channel, the community repository for bioinformatics packages, and the remaining names are the packages you want. Isolation matters for sensitive work because it makes your software versions explicit and reproducible. Expected output when installation succeeds: ``` # All requested packages installed successfully ``` Then verify versions: ```bash fastp --version samtools --version | head -1 ``` Expected output (your versions may differ): ``` fastp 0.24.0 samtools 1.21 ``` ### Step 3. Download a reference genome once, offline from then on Fetch the reference assembly once from a public source such as NCBI or Ensembl, store it on your encrypted disk, and never re-download it per analysis. Index it for alignment: ```bash bwa index GRCh38.fa samtools faidx GRCh38.fa ``` Expected output: ``` [bwa_index] Index building is done. ``` ### Step 4. Run the pipeline on local data ```bash # Quality control and adapter trimming fastp -i sample_R1.fastq.gz -I sample_R2.fastq.gz \ -o trimmed_R1.fastq.gz -O trimmed_R2.fastq.gz \ -h sample_fastp.html -j sample_fastp.json # Alignment, sorting, indexing bwa mem -t 8 GRCh38.fa trimmed_R1.fastq.gz trimmed_R2.fastq.gz | \ samtools sort -@ 8 -o sample.sorted.bam - samtools index sample.sorted.bam ``` Parameter notes. In `fastp`, `-i` and `-I` take the paired input reads, `-o` and `-O` the trimmed outputs, and `-h` and `-j` produce an HTML report and a JSON report you can keep as part of your local record. In `bwa mem`, `-t 8` requests eight threads, which you should match to your CPU core count. In `samtools sort`, `-@ 8` matches the thread count and the trailing `-` means read the alignment stream from standard input. ### Step 5. Check that the result is right ```bash samtools flagstat sample.sorted.bam ``` Expected output pattern (your numbers will differ): ``` 98765432 + 0 in total ... 96812345 + 0 primary mapped (98.03% : N/A) ``` What to look for. The primary mapped percentage should be high for a well-behaved sample against a matched reference. A sudden drop compared with previous runs of the same sample type usually points to the wrong reference build, corrupted input, or a swapped pair of FASTQ files. Also verify that `sample.sorted.bam.bai` exists, because downstream viewers and variant callers require the index. ### Step 6. Record integrity with checksums A checksum is a fixed-length fingerprint of a file. Recomputing it later proves the file has not changed. ```bash sha256sum sample_R1.fastq.gz trimmed_R1.fastq.gz sample.sorted.bam > manifest.sha256 sha256sum -c manifest.sha256 ``` Expected output: ``` sample_R1.fastq.gz: OK trimmed_R1.fastq.gz: OK sample.sorted.bam: OK ``` Keep `manifest.sha256` with the project. This one habit prevents the most common silent failure in local analysis, which is analyzing a truncated or partially copied file. ## Step-by-Step: Self-Hosting a Web Platform Behind Your Firewall If you prefer a graphical interface, or if collaborators on your network need one, host the interface yourself rather than sending data to a public server. ### Step 1. Deploy Galaxy locally Galaxy is an open workflow platform with a point-and-click interface. The standard local installation is: ```bash git clone https://github.com/galaxyproject/galaxy.git cd galaxy ./run.sh ``` The first run creates a virtual environment and downloads dependencies, which can take a while. Galaxy then serves on port 8080, so on the same machine you open `http://localhost:8080` and on other machines in your lab you use the host's internal IP address. Because the server runs inside your network, datasets uploaded through the interface stay on your storage. ### Step 2. Add proteomics capability With a local Galaxy running, you can install the tools used by PeptideShaker Online, namely SearchGUI, PeptideShaker, and moFF, from the Galaxy tool shed, and then serve the PeptideShaker Online interface from the same machine [5]. The end result matches the published architecture. Raw file conversion and identification happen on your Galaxy instance, and the interactive visualization happens through a web server you installed locally. ### Step 3. Containerize a clinical database stack For record-level clinical data, the Docker-based pattern described for intensive care databases is instructive [6]. In outline: ```bash docker compose up -d docker ps ``` Expected output from `docker ps` includes lines for each running container, for example a database container and an analytics interface container, each with a status such as `Up 2 minutes`. The published design deploys Metabase and Superset as web-based analytics interfaces alongside the database, and adds a locally deployed large language model integration so clinicians can request SQL queries in plain language [6]. Everything runs where you deployed it, which for the local option means your own server room or an air-gapped workstation. ### Step 4. Version control on an internal server Stand up a self-hosted Git service on a dedicated internal server for repository management and secure user access control, following the pattern of the academic deployment cited earlier [11]. This gives you an auditable history of every script, parameter file, and analysis notebook that touched your sensitive data. ### Step 5. Verify the whole stack is offline The most direct test is to disconnect the external network and run an end-to-end analysis. If your pipeline, your Galaxy instance, and your database interfaces all complete their work with the uplink unplugged, you have documented proof that the workflow is genuinely local. Schedule this test after any major software change. ## Tips for Working With Sensitive Data Locally **Separate identifiers from data at the boundary.** Encode patient identifiers into study codes before data touches the analysis disk, as the obesity data platform did by coding records with ICD-10 classifications and persisting them in anonymized form [8]. Keep the codebook on a different, more restricted system than the analysis data. **Encrypt at rest.** Use full-disk encryption on the workstation and, for extra protection on a shared server, encrypt the project directory itself: ```bash gpg -c project_archive.tar.gz ``` This produces `project_archive.tar.gz.gpg` and prompts for a passphrase. Store the passphrase in your institutional password manager, never in the project folder. **Write a metadata database, not a spreadsheet sprawl.** A local relational database such as SQLite or PostgreSQL gives you typed columns, access logs, and queryable sample tracking. The TefDB crop-genomics platform, while built for public data, illustrates the standard architecture. It pairs a React.js frontend with a Django and Python backend and PostgreSQL for [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices), handling tens of thousands of biological records with search, filtering, and download features [15]. The same stack, run on your own hardware, is a proven pattern for restricted data management. **Log every run.** Redirect tool logs into a dated directory: ```bash mkdir -p logs/$(date +%Y-%m-%d) fastp -i sample_R1.fastq.gz -I sample_R2.fastq.gz \ -o trimmed_R1.fastq.gz -O trimmed_R2.fastq.gz \ -h logs/$(date +%Y-%m-%d)/sample_fastp.html 2> logs/$(date +%Y-%m-%d)/sample_fastp.log ``` If you commit these logs to your internal Git server, you gain the traceability that the self-hosted platform study identified as a core benefit of version-controlled project documentation [11]. **Match analytic sensitivity to the question.** For alignment of repetitive genomic regions, prefer exact-match sensitive aligners such as DREAM-Stellar over heuristic search, because heuristic tools can miss significant local alignments entirely [13]. For proteomics ligand screening, the PELSA protocol and its companion software were written specifically because extracting binding proteins, binding regions, and binding affinities from the experiment is not trivial, and the software automates raw data processing through report generation [14][10]. **Use AI assistants carefully and locally where possible.** The ICU-GPT work shows the local pattern for AI-assisted analysis. Fine-tune or deploy the model component within your own Docker deployment, connect it to your local database through a framework such as LangChain, and let it generate SQL rather than export data [6]. The client-side prototype literature points the same direction, pairing locally persisted anonymized records with a structured Chain-of-Thought prompt framework for interpretation and reporting local storage performance among its feasibility outcomes [8]. The caution is maturity. Both were published as prototypes or descriptive studies, so validate outputs against known answers before trusting AI-generated queries or interpretations on clinical data. **Weigh the maintenance cost honestly.** The cloud proteomics platform authors argue that local pipelines glued together with in-house scripts are costly to maintain and scale [3]. That criticism is fair for ad hoc script collections, and it is the strongest argument for the structured local options in this article. Conda environments, Docker containers, self-hosted Galaxy, and version control exist precisely to make local stacks maintainable rather than fragile. ## Common Mistakes and Limitations ![Decision path asking where the server runs, whether the paper names cloud compute, and whether the data can be de-identified.](/article-images/illustrations/best-local-bioinformatics-software-sensitive-data-is-it-local.webp) **Assuming a graphical tool is local.** A browser interface proves nothing about where data goes. A web platform that eliminates local installations and large file uploads is, by design, shipping your files to a remote server [1]. Before using any GUI, read the deployment model. If the architecture section of the paper mentions TACC, a cloud data lake, or managed cloud compute, as the DOCKweb molecular modeling platform does with calculations executed at the Texas Advanced Computing Center [2], and as the MSAID proteomics platform does with cloud instances [3], the analysis is not local regardless of how the interface feels. **De-identifying too late.** If raw identifiable data is copied to an unencrypted analysis laptop first and pseudonymized later, the sensitive version has already existed on vulnerable storage. Encode identifiers at the point of data entry, as the client-side medical records prototype did with ICD-10 coded, anonymized persistence [8]. **Skipping the manifest.** Analyzing a corrupted or partially transferred file wastes days and produces confident-looking wrong results. Always write checksums before analysis and verify with `sha256sum -c` before starting [see Step 6 above]. **Wrong reference build.** Aligning reads against a mismatched genome assembly produces low mapping rates and spurious variant calls. Record the exact assembly version and download source for the reference in your project log, and never rely on a file named `genome.fa` without provenance. **Confusing analytic sensitivity with data sensitivity.** A sensitive aligner that misses fewer true homologies [13] says nothing about privacy, and an encrypted disk says nothing about whether your variant caller detects low-frequency mutations. You need to manage both meanings deliberately. **Ignoring reproducibility until publication.** Reviewers and collaborators will ask which software versions produced which results. Fixed conda environments, container images, and a self-hosted version control server with secure access control solve this, and the published academic deployment demonstrated the full cycle by developing a new bioinformatics package on such a platform [11]. **Overtrusting AI-generated code or SQL.** Locally deployed language model interfaces can generate queries that run without errors and return subtly wrong results, especially across multischema databases [6]. Test generated queries against hand-written equivalents on a small subset before applying them to the full dataset. **Forgetting that local does not mean unregulated.** A clinical pipeline used for patient reporting must meet your laboratory's accreditation requirements. tbtAMR shows what that looks like in practice, with validation against phenotypic susceptibility results and accreditation to ISO standards [7]. Recreate that validation discipline locally rather than assuming offline operation is automatically compliant. **One limitation to state plainly.** Individual projects differ in data type, volume, threat model, and institutional policy, and a workstation setup that is adequate for one laboratory may be inadequate for another. Consult your institution's data governance or information security office for requirements that apply to your specific dataset, and involve a veterinarian or physician, as applicable, before clinical decisions based on any computational result. ## Frequently Asked Questions ### What counts as sensitive data in bioinformatics? Any dataset that could identify a person or reveal confidential information. Human genome sequences are inherently identifiable, and linking them to clinical records, images, or demographic metadata increases the risk. Datasets where a codebook maps sample codes to individuals also qualify even if the shared files look anonymous. ### Is a locally installed web application really local? Yes, if the server process runs on your machine. PeptideShaker Online is a published example of the pattern, with data storage and processing on a Galaxy backend you install and only the browser interface served locally [5]. A browser interface alone proves nothing, so always confirm where the server and storage actually run. ### Can I use web bioinformatics platforms if I de-identify the data first? De-identification reduces risk but does not make data harmless, because genomic data itself is identifying. A reasonable middle path, used by the SEED health atlas, is to publish only de-identified and aggregated data [9]. For record-level or sequence-level restricted data, keep processing local. ### Do local tools give up too much performance compared to cloud platforms? Not on well-optimized software. DREAM-Stellar reaches the runtime of common search tools while finding alignments that heuristic tools miss, and runs up to 900 times faster on 32 threads than its single-threaded predecessor [13]. Cloud platforms win mainly on elastic scaling for very large recurring workloads [3], not on raw per-sample analysis. ### What hardware do I need for a local bioinformatics workstation? For small projects, a modern desktop with a multicore CPU, 32 GB of RAM, and fast SSD storage handles bacterial genomes, transcriptomes, and typical proteomics analyses. For human genomes and large cohort work, more memory and storage are needed, and space-efficient algorithms help. DREAM-Stellar was specifically designed for parallel and space-efficient exact alignment on large genomic datasets [13]. ### How do I make local analyses reproducible? Pin software versions in conda environments or containers, write checksum manifests for every input and output file, and keep all scripts and parameter files under version control. A self-hosted Git platform with secure access control provides both the history and the access management, as demonstrated in an academic deployment that produced a complete bioinformatics package on such infrastructure [11]. ### Can I use large language models with sensitive data without uploading it? Yes, by deploying the model and the data together on your own infrastructure. The ICU-GPT platform deploys clinical databases via Docker in local, cloud, or remote environments and pairs them with a locally connected language model that generates SQL queries, so the data path can stay entirely inside your deployment [6]. Validate generated queries and interpretations before clinical use. ### Which local software should a clinical microbiology laboratory start with? Start with a pipeline built for accredited clinical use rather than a research tool. tbtAMR takes FASTQ reads or an annotated VCF file, maps variants across several mutation classes, interprets resistance against the WHO catalogue or a user-defined database, and produces clinical-report-ready output, with validation against phenotypic and genomic reference data and ISO standards accreditation [7]. ## Sources 1. [H(3)NGST: a fully automated, web-based platform for end-to-end ChIP-seq analysis.](https://pubmed.ncbi.nlm.nih.gov/41068566/) 2. [DOCKweb: a web-based GUI platform for molecular modeling with DOCK6.](https://pubmed.ncbi.nlm.nih.gov/42406155/) 3. [A Scalable, Web-Based Platform for Proteomics Data Processing, Result Storage and Analysis.](https://pubmed.ncbi.nlm.nih.gov/39982847/) 4. [Profiler: an open web platform for multi-omics analysis.](https://pubmed.ncbi.nlm.nih.gov/41324558/) 5. [PeptideShaker Online: A User-Friendly Web-Based Framework for the Identification of Mass Spectrometry-Based Proteomics Data.](https://pubmed.ncbi.nlm.nih.gov/34709836/) 6. [Large Language Model-Based Critical Care Big Data Deployment and Extraction: Descriptive Analysis.](https://pubmed.ncbi.nlm.nih.gov/40079079/) 7. [Bringing tuberculosis genomics to the clinic: development and validation of a comprehensive pipeline to predict antimicrobial susceptibility from genomic data, accredited to ISO standards.](https://pubmed.ncbi.nlm.nih.gov/41436327/) 8. [System architecture and interactive LLM prompt framework for the integration of clinical and mitochondrial data in obesity: a software prototype and feasibility study.](https://pubmed.ncbi.nlm.nih.gov/42787219/) 9. [SEED: A novel web-based data visualization platform to visualize, communicate, and explore social, environmental, and equity drivers of health.](https://pubmed.ncbi.nlm.nih.gov/39345710/) 10. [PELSA-Decipher: A Software Tool for the Processing and Interpretation of Ligand-Protein Interaction Data Sets Acquired by PELSA.](https://pubmed.ncbi.nlm.nih.gov/40804637/) 11. [Implementing a Version Control Platform as an Interactive Educational Framework for Bioinformatics and Artificial Intelligence in Medicine.](https://pubmed.ncbi.nlm.nih.gov/42719450/) 12. [SimpleMicrobiome: An integrated web-based platform for streamlined microbiome data analysis and visualization.](https://pubmed.ncbi.nlm.nih.gov/42754330/) 13. [DREAM-Stellar: parallel and space efficient exact local alignment.](https://pubmed.ncbi.nlm.nih.gov/41709133/) 14. [Peptide-centric local stability assay (PELSA) for sensitive identification of ligand-targeting proteins and binding sites at proteome scale.](https://pubmed.ncbi.nlm.nih.gov/42020566/) 15. [Developing a web-based platform for Eragrostis tef resource management and analysis.](https://pubmed.ncbi.nlm.nih.gov/42639803/)