appwrite-utils-cli
is a powerful command-line interface tool designed for Appwrite developers who need to manage database migrations, schema generation, data import, and much more. This CLI tool facilitates complex tasks like setting up databases, running migrations, generating schemas, and managing backups efficiently, making it an indispensable part of your Appwrite project management.
- Easy Configuration: Initialize your Appwrite project configurations interactively directly from the command line.
- Database Migrations: Control the migration process with options to target production, staging, or development environments.
- Schema Generation: Generate and manage TypeScript schemas directly from your Appwrite database schemas.
- Data Import: Facilitate the import of data into your Appwrite databases with comprehensive command-line support.
- Backup Management: Create backups of your Appwrite databases to ensure data integrity and safety.
- Flexible Database Management: Includes commands to wipe databases, documents, or user data, providing flexibility in managing your database state during development or testing.
- Transfer Databases, Collections, Documents, Storage Buckets, and more: Includes additional commands (new) to transfer your data from one place to another. I also optimized the import process using this.
To use appwrite-utils-cli
, you can install it globally via npm to make it accessible from anywhere in your command line:
npm install -g appwrite-utils-cli
However, due to the nature of the speed at which I am developing this project, I would recommend the following command:
npx --package=appwrite-utils-cli@latest appwrite-migrate --arg1 --arg2 --arg3
DO NOT INSTALL THIS LOCALLY INTO YOUR PROJECT, IT IS MEANT TO BE USED AS A COMMAND LINE TOOL ONLY
After installation, you can access the tool directly from your command line using the provided commands. Here's how you can use the different functionalities:
Interactively set up your Appwrite project with necessary configurations:
npx --package=appwrite-utils-cli@latest appwrite-init
Run migration and management tasks with specific flags according to your needs:
npx --package=appwrite-utils-cli@latest appwrite-migrate --args
Replace --args
with the appropriate options:
-
--prod
: Run tasks in the production environment. -
--staging
: Run tasks in the staging environment. -
--dev
: Run tasks in the development environment. -
--wipe
: Wipe all databases. -
--wipe-docs
: Wipe all documents in the databases. -
--generate
: Generate TypeScript schemas from database schemas. -
--import
: Import data into your databases. -
--backup
: Perform a backup of your databases. -
--wipe-users
: Wipe all user data. -
--write-data
: Write converted imported data to file. -
--sync
: Synchronize your project's config and generate schema for your database. -
--endpoint <endpoint>
: Set the Appwrite endpoint. -
--project <project>
: Set the Appwrite project ID. -
--key <key>
: Set the Appwrite API key. -
--transfer
: Transfer documents between databases. -
--transfer-users
: Transfer users between local and remote. -
--transferendpoint <transferEndpoint>
: Set the transfer endpoint for remote transfers. -
--transferproject <transferProject>
: Set the transfer project ID for remote transfers. -
--transferkey <transferKey>
: Set the transfer key for remote transfers. -
--fromdb <fromDbId>
: Set the source database ID. -
--targetdb <targetDbId>
: Set the destination database ID. -
--fromcoll <collectionId>
: Set the source collection ID for transfer, only used for transfer. -
--targetcoll <collectionId>
: Set the collection ID to import data into. -
--frombucket <bucketId>
: Set the source bucket ID. -
--targetbucket <bucketId>
: Set the destination bucket ID.
Transfer databases within the same project or from a local to a remote project. If --fromcoll
and --targetcoll
are omitted, it will transfer the entire databases. During the database transfer, it will create any missing collections, attributes, and indices.
npx appwrite-utils-cli appwrite-migrate --transfer --fromdb fromDbId --targetdb toDbId --transferendpoint https://appwrite.otherserver.com --transferproject yourProjectId --transferkey yourApiKey
Transfer specific collections from one place to another, with all of their data.
npx appwrite-utils-cli appwrite-migrate --transfer --fromdb fromDbId --targetdb toDbId --fromcoll sourceCollectionId --targetcoll targetCollectionId --transferendpoint https://appwrite.otherserver.com --transferproject yourProjectId --transferkey yourApiKey
Transfer files between buckets.
npx appwrite-utils-cli appwrite-migrate --transfer --frombucket sourceBucketId --targetbucket targetBucketId --transferendpoint https://appwrite.otherserver.com --transferproject yourProjectId --transferkey yourApiKey
Transfer users between local and remote.
npx appwrite-utils-cli appwrite-migrate --transfer-users --transferendpoint https://appwrite.otherserver.com --transferproject yourProjectId --transferkey yourApiKey
This happens because Node only allocates 4 GB, it'll only happen if you're importing a ton of data, but you can use export NODE_OPTIONS="--max-old-space-size=16384"
or the relevant command for your system if that doesn't work, and it'll set the env var to whatever. That's 16 GB, I would recommend 8192
for most.
Recently, I have also added an optional OpenAPI generation for each attribute in the schema. This is because I needed it and because I felt it would be nice to have. This is done using this package, many thanks to them.
To use it, add a description
to any attribute or collection, and it will export that schema to the appwrite/openapi
folder
This setup ensures that developers have robust tools at their fingertips to manage complex Appwrite projects effectively from the command line. I also have added logging automatically for information and errors as the console can be hard to keep up with.
- Syncing configuration (DONE)
- Better file format for config (potentially)
- Separation of collections and import configuration from main config
- 0.0.55: Added
documentExists
check to batch creation functionality to try to prevent duplicates - 0.0.54: Various fixes in here
- 0.0.50: Actually fixed the slight bug, it was really in the
mergeObjects
- 0.0.49: Fixed a slight bug with
dataLoader
not mapping updates correctly withupdateMapping
- 0.0.48: Added
--transfer
,--fromdb <targetDatabaseId>
,--targetdb <targetDatabaseId>
,--transferendpoint <transferEndpoint>
,--transferproject <transferProjectId>
,--transferkey <transferApiKey>
. Additionally, I've added--fromcoll <collectionId>
and--targetcoll <collectionId>
. These allow you to do a few things. First, you can now transfer databases in the same project, and from local to a remote project. Second, you can now specify specific collections to transfer from one place to another, with all of their data. If--fromcoll
and--targetcoll
are ommitted, it will transfer the databases. During the database transfer, it will create any missing collections, attributes, and indices. - 0.0.47: Minor bugfixes in many releases, too small to take note of
- 0.0.38: Lots of optimizations done to the code, added
tryAwaitWithRetry
forfetch failed
and others like it errors (looking at youserver error
) -- this should prevent things from going sideways. - 0.0.37: Added
documentSecurity
,enabled
, and$id
to theinit
collection - 0.0.36: Made it update collections by default, sometimes you gotta do what you gotta do
- 0.0.35: Added update collection if it exists and permissions or such are different (
documentSecurity
andenabled
), also added a check forfetch failed
errors to retry them with recursion, not sure how well that will work out, but we're gonna try it! It will still fail after 5 tries, but hopefully that gives Appwrite some time to figure it's stuff out - 0.0.34: Fixed the
bin
section of the package.json, apparently you can't usenode
to run it - 0.0.33: Fixed
idMappings
, if you are importing data and use theidMappings
functionality, you can set afieldToSet
based on the value of asourceField
in the current imported items data (whether it's in the final data or the original), in order to match another field in another collection. So if you had a store, and it had items and the items have a Region ID for instance. You can then, in your regionId of the items, setup anidMapping
that will allow you to map the value of thetargetField
based on the value of thetargetFieldToMatch
in thetargetCollection
. Sounds complex, but it's very useful. Like psuedo-relationship resolution, without the relationships. - 0.0.29: If you use the
description
variable in an attribute and collection, it'll add that description to the generated schemas. This assumes you havezod-to-openpi
- 0.0.275: THINGS ARE NOW IN TYPESCRIPT WOOHOO. No but for reaal, super happy to report that everything has been converted to TypeScript, just way too many changes, I hope you enjoy it!
- 0.0.274: Small improvement for attribute handling, rather than getting it every attribute, I check the collections attributes
- 0.0.273: Small fix for relationship attribute comparisons
- 0.0.272: That's what I get for not testing lmao, also updated logic for checking for existing attributes to take the
format
into consideration from the database (URL's are not oftype: "url"
, they are offormat: "url"
) - 0.0.271: Small change to update attributes that are different from each other by deleting the attribute and recreating, as we cannot update most things
- 0.0.270: Fixed enums in
--sync
, added optional OpenAPI generation (in progress, almost done, but wanted to push other changes), added--endpoint
,--project
,--key
as optional parameters to change the target destination (shoutout to pingu24k for pointing out these bugs and suggesting those changes for endpoint customization) - 0.0.254: Added
--sync
to synchronize your Appwrite instance with your localappwriteConfig.yaml
and generate schemas - 0.0.253: Added
--writeData
(or--write-data
) to command to write the output of the import data to a file called dataLoaderOutput in your root dir - 0.0.23: Added batching to user deletion
- 0.0.22: Converted all import processes except
postImportActions
and Relationship Resolution to the local data import, so it should be much faster. - 0.0.6: Added
setTargetFieldFromOtherCollectionDocumentsByMatchingField
for the below, but setting a different field than the field you matched. The names are long, but at least you know what's going on lmao. - 0.0.5: Added
setFieldFromOtherCollectionDocuments
to set an array of ID's for instance from another collection as apostImportAction