## Migration from Pleroma {#modules-services-akkoma-migration-pleroma}

Pleroma instances can be migrated to Akkoma either by copying the database and upload data or by
pointing Akkoma to the existing data. The necessary database migrations are run automatically
during startup of the service.

The configuration has to be copy‐edited manually.

Depending on the size of the database, the initial migration may take a long time and exceed the
startup timeout of the system manager. To work around this issue one may adjust the startup timeout
{option}`systemd.services.akkoma.serviceConfig.TimeoutStartSec` or simply run the migrations
manually:

```ShellSession
pleroma_ctl migrate
```

### Copying data {#modules-services-akkoma-migration-pleroma-copy}

Copying the Pleroma data instead of re‐using it in place may permit easier reversion to Pleroma,
but allows the two data sets to diverge.

First disable Pleroma and then copy its database and upload data:

```ShellSession
# Create a copy of the database
nix-shell -p postgresql --run 'createdb -T pleroma akkoma'

# Copy upload data
mkdir /var/lib/akkoma
cp -R --reflink=auto /var/lib/pleroma/uploads /var/lib/akkoma/
```

After the data has been copied, enable the Akkoma service and verify that the migration has been
successful. If no longer required, the original data may then be deleted:

```ShellSession
# Delete original database
nix-shell -p postgresql --run 'dropdb pleroma'

# Delete original Pleroma state
rm -r /var/lib/pleroma
```

### Re‐using data {#modules-services-akkoma-migration-pleroma-reuse}

To re‐use the Pleroma data in place, disable Pleroma and enable Akkoma, pointing it to the
Pleroma database and upload directory.

```nix
{
  # Adjust these settings according to the database name and upload directory path used by Pleroma
  services.akkoma.config.":pleroma"."Pleroma.Repo".database = "pleroma";
  services.akkoma.config.":pleroma".":instance".upload_dir = "/var/lib/pleroma/uploads";
}
```

Please keep in mind that after the Akkoma service has been started, any migrations applied by
Akkoma have to be rolled back before the database can be used again with Pleroma. This can be
achieved through `pleroma_ctl ecto.rollback`. Refer to the
[Ecto SQL documentation](https://hexdocs.pm/ecto_sql/Mix.Tasks.Ecto.Rollback.html) for
details.

## Advanced deployment options {#modules-services-akkoma-advanced-deployment}

### Confinement {#modules-services-akkoma-confinement}

The Akkoma systemd service may be confined to a chroot with

```nix
{
  services.systemd.akkoma.confinement.enable = true;
}
```

Confinement of services is not generally supported in NixOS and therefore disabled by default.
Depending on the Akkoma configuration, the default confinement settings may be insufficient and
lead to subtle errors at run time, requiring adjustment:

Use
[{option}`services.systemd.akkoma.confinement.packages`](options.html#opt-systemd.services._name_.confinement.packages)
to make packages available in the chroot.

{option}`services.systemd.akkoma.serviceConfig.BindPaths` and
{option}`services.systemd.akkoma.serviceConfig.BindReadOnlyPaths` permit access to outside paths
through bind mounts. Refer to
[`BindPaths=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#BindPaths=)
of {manpage}`systemd.exec(5)` for details.

### Distributed deployment {#modules-services-akkoma-distributed-deployment}

Being an Elixir application, Akkoma can be deployed in a distributed fashion.

This requires setting
[{option}`services.akkoma.dist.address`](options.html#opt-services.akkoma.dist.address) and
[{option}`services.akkoma.dist.cookie`](options.html#opt-services.akkoma.dist.cookie). The
specifics depend strongly on the deployment environment. For more information please check the
relevant [Erlang documentation](https://www.erlang.org/doc/reference_manual/distributed.html).