AzurLaneAutoScript: a Python bot that takes over Azur Lane on CN, EN, JP and TW servers

What Alas automates, and the assumption baked into it

Alas targets a narrow audience: players who already run Azur Lane on an emulator or cloud phone and want the game's repetitive loops executed without a human. The README lists four gameplay groups it takes over. Sorties covers main-story maps, event maps, cooperative events and emergency commissions farmed for diamonds. Collection covers commissions, the tactical academy, research, the dorm, meowfficers, guild, shop purchases, the development dock, daily gacha and archive keys. Dailies covers daily missions, hard maps, exercises, submarine maps, event daily A/B and SP maps, cooperative dailies and operation archives. Operation Siren covers Ashes beacons, monthly exploration, dailies, hidden zones, the short-cat patrol, abyssal zones and Siren strongholds.

The README does not present this as a convenience tool. It states the position directly: Azur Lane, as a mobile game, has entered the late stage of its life cycle, and players should reduce time spent on it and leave everything to Alas. That framing matters because it shapes the whole design. There is no attempt to keep a human in the loop, no partial-automation mode the README recommends, and no encouragement to babysit the process. The intended deployment is a machine that runs the bot continuously while you ignore the game.

The project is free and open source under GPL-3.0, with the repository at github.com/LmeSzinc/AzurLaneAutoScript and a homepage at alas.azurlane.cloud. The README credits named contributors for the EN, JP and TW localisations and for the GUI. TW is flagged in the README as having features that might not work, so server parity is not uniform.

How the scheduler and mood control actually behave

The mechanism the README explains at most length is the scheduler, and it is the part most likely to surprise a new user. Every task runs independently and is dispatched by one shared scheduler. When a task finishes, it sets its own next run time. The README's example: if the research task completes a four-hour research, the scheduler pushes the research task back four hours. This is what the README calls seamless collection. The consequence is that tasks are not on a fixed cron-like grid; their cadence is derived from in-game completion times, which is why the README treats the scheduler as the primary interface rather than a list of buttons.

Mood control works the same way, by prevention rather than reaction. The README states Alas does not wait for the red-face popup; it keeps mood above 120 to hold the 20 percent experience bonus. Its example: at 113 mood, placed on the dorm's second floor (+50/h), unmarried (+0/h), Alas waits about 12 minutes for mood to recover past 120 before sortieing again, and fills that wait with other tasks. That interleaving is the point. A scheduler that only delayed one task would idle the device; this one uses the gap.

The README is blunt about how to use this: the wrong way is to enable one or two tasks and manage them by hand, the right way is to enable every task you think might be useful, let the scheduler run, and minimise both the emulator and Alas to the tray. If you intend to keep manual control, the scheduler's design works against you.

Installing AzurLaneAutoScript and running a first sortie

The README does not inline install commands. It points to a wiki page, Installation_cn, which it says contains an automatic install tutorial, a usage tutorial, a manual install tutorial and a remote-control tutorial, plus a separate Emulator_cn page covering emulator, cloud phone and other device setups. The repository also ships a docker-compose.yml, so a container path exists for people who prefer it.

The compose file defines one service named ALAS, uses host networking, and mounts the current directory into /app/AzurLaneAutoScript. It builds from ./deploy/docker/Dockerfile, with a commented-out ./Dockerfile.cn alternative. It also mounts /etc/localtime read-only and names the container alas.

version: '3.7'
services:
    ALAS:
        network_mode: host
        volumes:
            - '.:/app/AzurLaneAutoScript:rw'
            - '/etc/localtime:/etc/localtime:ro'
        container_name: 'alas'
        image: 'alas'
        build:
            context: ./deploy/docker/
            dockerfile: ./Dockerfile

Because the build context is a subdirectory of the repository, the compose file is meant to be run from the repository root, and the bind mount means the container reads and writes the checkout you already have rather than a copy inside the image.

Before any of that is useful, the README requires you to change in-game settings. The table covers the options menu (60 FPS, reduce TB guidance on, auto-submit items during autopilot on, safe-sea autopilot off by default, auto-play story on and at the fastest speed, standby mode off, duplicate-ship prompts off, quick-swap confirmation off, settlement character display off), the Operation Siren radar order module (uncheck submarine sortie at X consumption), and the retirement settings (priority 1 R, priority 2 SR, priority 3 N, keep zero same-name ships when a fully-starred copy exists, and keep either the number needed for full stars or none when it does not). The README also asks you to remove equipment skins from ships because they interfere with image recognition. Treat this table as a prerequisite, not a suggestion; the README says so in as many words.

The dependency set is pinned and old. requirements.txt was generated by pip-compile for Python 3.7 and pins adbutils==0.11.0, uiautomator2-adjacent packages, cnocr==1.2.2, gluoncv==0.6.0, av==10.0.0 and alas-webapp==0.3.7 among others. That pinning is a deliberate reproducibility choice, but it also means the environment is not something you can casually upgrade piece by piece.

Map recognition, and why template matching is not enough

The README singles out map recognition as the core of the project and links a dedicated wiki page on perspective. The argument is stated plainly: if you rely on template matching alone to find enemies, you will inevitably hit the case where a boss is blocked by mobs. Alas instead exposes full sea-zone information from module.map_detection, and the README shows a sample log where each grid cell is labelled with a symbol such as ++, ==, FL, MY or 2E.

That output is the interesting part of the architecture. A bot that only knows whether a template matched can decide to click or not. A bot holding a labelled grid can reason about the map as a structure, which is what lets the README claim support for non-clearing mode, movement-distance limits, light walls, coastal guns, map puzzles and map mazes in event exploration. Those are the mechanics where a naive clicker stalls.

The README also credits the lineage here. It says Alas borrowed its architecture from ALAuto, an EN-server script that is no longer maintained, and that it brought the homography transform from ALAuto's homg_trans_beta branch into the map-recognition module. That is a useful signal about where the hard problems live: the perspective handling is inherited, not invented from scratch.

Known failure modes before you commit hardware

The known-issues list is unusually candid and should be read as a requirements document for your setup. First, Alas cannot handle network fluctuations, reconnect popups or the game's yellow-chicken interruption. If your connection is unstable, the bot stops being unattended.

Second, performance is a hard constraint. The README says very low-end machines cause assorted problems, and defines very low-end as a screenshot taking longer than 1 second. Typical machines take about 0.5 seconds and high-end about 0.3 seconds. This is a screenshot-latency budget, not a frame-rate one, and it is the number to check on your own hardware before trusting the bot.

Third, exercise SL can fail. The README explains that SL watches the health bar at the top of the screen, that the bar can be covered by character art, and that the default behaviour waits about 1 second for health to drop below roughly 40 percent. A backline at low health has around 30 percent of the bar, so it can die inside that window.

Fourth, ADB and uiautomator2 occasionally misbehave, which the README attributes to the emulator and resolves by restarting it. Fifth, drag operations are interpreted as taps when the emulator stutters. All five are environmental, which means the bot's reliability is partly a property of your emulator choice, and the README's emulator wiki page is the place it points you for that.

A different kind of limitation is the game itself. The README's own premise is that Azur Lane is late in its life cycle. A tool that automates a live-service game inherits the risk that the game changes or ends.

Alternatives: ALAuto, and the wider ecosystem the README points at

The README names ALAuto (Egoistically/ALAuto) as the EN-server Azur Lane script that Alas copied its architecture from, and states that ALAuto is no longer maintained. The practical difference today is maintenance and scope rather than approach: ALAuto was EN-only, while Alas covers CN, EN, JP and TW and adds the Operation Siren automation that dominates the feature list. If you find an old ALAuto guide, the architectural ideas transfer but the code path does not.

The README also points to neighbouring projects that are not alternatives but complements. AzurStats is a drop-statistics platform built on Alas. AzurLaneUncensored is a separate repository that interfaces with Alas. PyWebIO is the GUI library Alas uses, and MaaAssistantArknights appears in the related-projects list as a sibling automation project in the same ecosystem. None of these replace Alas; they assume it.

For a genuinely different approach, the README's own framing is the comparison: Alas aims to take over nearly all gameplay with a scheduler that decides when to run each task. A narrower script that performs one loop on demand would be easier to reason about and easier to keep running after a game update, but it would not deliver the seamless-collection behaviour the README builds the project around. That is the trade you are making.

Maintenance, upgrades and the GPL-3.0 licence

The repository is not archived and the last push was on 2026-09-20, one day before this was written, so the codebase is moving. The release cadence is slower than the commit cadence: recent releases are v2026.03.27 (Easy Install v0.4.10) on 2026-03-28, v2025.07.13 (Easy Install v0.4.9) on 2025-07-13, and v2025.01.19 (Easy Install v0.4.8) on 2025-01-20. The gap between a tagged release and the current master is therefore potentially months of changes, which is worth knowing if you plan to follow releases only.

Upgrade cost is dominated by the pinned requirements. requirements.txt is a pip-compile lock file generated for Python 3.7, so moving to a newer interpreter is not a matter of editing one line; the whole lock has to be regenerated and the pinned ML and OCR packages re-resolved. If you install from a release rather than tracking master, you inherit whatever that release pinned.

The licence is GPL-3.0. In practical terms for an end user, that means the software is free to run and modify, and if you redistribute a modified version you carry the GPL's obligations with it. This is a summary of the licence identifier in the repository, not legal advice; read the LICENSE file if redistribution is part of your plan.

There is also a community dimension the README treats as part of the product. It links a Discord server and a QQ group, and the bug-reporting section asks for at least five minutes of preparation before posting, pointing to the FAQ wiki first, then to the log/error directory where each failure is stored in a folder named with a millisecond timestamp containing log.txt and the most recent screenshots. For non-error misbehaviour it asks for the day's log from the log directory plus at least one game screenshot. Reports that just say the bot will not run or is stuck are, per the README, not answered.

Editorial conclusion

Adopt Alas if you already run Azur Lane on an emulator or cloud phone and want the daily, event and Operation Siren loops handled without supervision; the README's own framing is that you should hand the game over entirely rather than toggle the bot by hand. Skip it if you play on a physical phone you also use for other things, if you want a tool that reacts to network drops and reconnect popups (the known-issues list says it cannot), or if you are not willing to change roughly a dozen in-game settings to match the table in the README. Before committing, verify three things on your own hardware: that a screenshot round trip stays near the 0.5s the README cites as typical, that your emulator survives the ADB and uiautomator2 hiccups the README attributes to the emulator, and that your server's features actually work (the README notes TW support is partial).

Frequently asked questions

Official sources

1. License: GPL-3.0
2. LmeSzinc/AzurLaneAutoScript on GitHub
3. Project website
4. README
5. Releases