# Upgrading to GROWI v7.5.x

GROWI v7.5 focuses on expanding AI integration through the new /ai-tools API surface and strengthening awareness of other users during simultaneous collaborative editing.

# Table of Contents

# For Users

# [New Feature] Introduction of the /ai-tools API for AI integration

A new set of API endpoints, /ai-tools, has been added to make GROWI more useful from external AI agents.

As the first endpoint in this series, we have implemented an API that suggests candidate page paths based on page content. This allows an AI agent to suggest an appropriate location when a user creates a new page.

Going forward, both GROWI AI features and features exposed to external AI agents will be built on top of this API surface.

# [New Feature] Avatars displayed at other users' cursor positions in collaborative editing

When multiple users edit the same page simultaneously, each user's avatar is now displayed next to their cursor position. You can see who is editing which part of the page at a glance.

  • Other users' avatars are shown near their caret inside the editor
  • For users editing outside the currently visible editor viewport, indicators are shown along the edge of the editor
  • Clicking an avatar on an indicator scrolls the editor to the location that user is editing

# [New Feature] Emacs markdown-mode keybindings in the editor

When the editor keybinding mode is set to Emacs, keybindings equivalent to Emacs markdown-mode (opens new window) are now available.

In addition to fixing keybindings that had regressed in the v7.4 series, new keybindings aligned with markdown-mode have been added.

The behavior where visiting a link such as /path/to/page#anchor sometimes failed to scroll to the #anchor position has been improved. A re-scroll step now runs after lazily-rendered elements (code blocks, plugin output, etc.) finish rendering.

WARNING

Note that this does not resolve every case.

# For Administrators

# [Security] Change of the base image used by the official Docker image

The base image of the official GROWI Docker image has been changed to Docker Hardened Images (DHI) (opens new window). With bundled packages reduced to a minimum, the attack surface of the running container is smaller and GROWI can be operated more securely.

On the other hand, DHI is a minimal image that does not include shells (sh, bash) or a package manager. Operational patterns that rely on entering the container interactively with docker exec for debugging are no longer possible.

WARNING

If you are running a customized build on top of the official Docker image, verify that there is no operational impact before upgrading to v7.5.x. Typical patterns to review: installing additional packages, using a custom entrypoint, or relying on steps that assume in-container shell access.

# [Specification Change] Change of the S3 upload method

# Background

Previously, S3 file uploads used a single PutObject operation. Starting with v7.5, multipart upload is used instead.

# Changes

Version S3 upload method
v7.4.x and earlier Single PutObject operation
v7.5.x and later Multipart upload (falls back to PutObject for files 5 MB or smaller)

# Action

Add the s3:AbortMultipartUpload permission to your IAM policy.

TIP

CreateMultipartUpload, CompleteMultipartUpload, and UploadPart are covered by s3:PutObject in IAM, so s3:AbortMultipartUpload is the only permission that needs to be added.

# [New Feature] Bulk export of audit logs

The audit log view in the admin panel now supports bulk export of audit log entries. This is useful for archival purposes and for analysis in external tools.

  • From Admin > Audit Log, you can run an export with filter conditions applied
  • The export dialog is automatically pre-filled with the currently applied filter conditions, so the range visible on screen can be exported as-is

# Things to Check Before Upgrading

  • Are you using S3 or S3-compatible object storage?
    • Has the s3:AbortMultipartUpload permission been added to your IAM policy?
  • Are you using the official GROWI Docker image?
    • Does your operation avoid relying on in-container shell access or installing additional packages at runtime?
    • If you use a custom entrypoint or a derived image, have you verified that it works on top of Docker Hardened Images?