@tahc.ia/tahcia

https://www.tahcia.com https://www.tahcia.com/business https://www.tahcia.com/contact [email protected]

Run Antigravity as a Tahcia AI Worker on your remote development server.

Tahcia lets you control Antigravity from the AI Workers tab and have it modify your actual Git workspace on the server.

The setup is designed for two-sided development:

• Work remotely from Tahcia when you are away from your computer.
• Work locally from your IDE when you are at your computer.
• Use Git to hand the workspace from one side to the other.
• See AI changes live before publishing them.
• Publish approved changes to a second development URL.

The Two-Sided Development Model

The server has one Git repository and two Apache virtual hosts:

                    Git Repository
                         │
                         │
                 /var/www/dev
                         │
              ┌──────────┴──────────┐
              │                     │
         dev.example.com      git history
              │
              ▼
       AI working version

After you are happy with the changes:

/var/www/devA
      │
      │ tell antigravity to git commit
      ▼
   Git history
      │
      │ tell antigravity to run script to publish
      ▼
/var/www/devB
      │
      ▼
devB.example.com

The important distinction:

devA.example.com Points directly to: /var/www/devA

This is where Antigravity works. Every change Antigravity makes is immediately visible here.

devB.example.com Points to: /var/www/devB

This is the published version. It only changes when you explicitly publish the approved Git version.

Remote Development From Tahcia

Create an AI Worker in Tahcia:

Agent Type: antigravity

Configure its workspace:

Host URL: https://devB.example.com:6999
Workplace Folders: /var/www/devA

You can include additional folders with: + Include This Folder You can also specify Python Path when the project requires a virtualenv or custom Python executable.

Start the Worker

On the Linux / Ubuntu development server:

pip install psutil google-antigravity
npm i -g @tahc.ia/tahcia
export TAHCIA_API_KEY="YOUR_TAHCIA_API_KEY"
tahcia run antigravity

You can now through Tahcia talk to your server, it doesn't ask permission to act but it does basic limited operation for coding.

Open the Antigravity worker and start a conversation.

Remote Workflow

Suppose you are away from your computer.

You open Tahcia on your phone and tell Antigravity:

git pull
Fix the checkout page so the total updates immediately when the quantity changes.

Antigravity works directly in: /var/www/devA and you can immediately open: https://devA.example.com and see what Antigravity changed.

Don't Like It?

revert git to main

Like It?

submit to git

Then publish the approved version to /var/www/devB.

For example, you can provide:. /var/www/devA/publish_to_devB.sh and add it to gitignore. Antigravity will know exactly what you mean when you say "use script to publish to devB"

Now: https://devB.example.com shows the approved version.

Local Workflow

When you are back at your computer, you do not need Tahcia. Local editing is often faster for small changes. Pull the commits made remotely:

git pull

Then open the project in your normal IDE:

Cursor / VS Code / Windsurf / Antigravity / etc.

Make changes locally. Your existing IDE upload/sync workflow can upload the files directly to:

/var/www/devB

You do not need Git for every tiny edit. For example:

Local IDE
   │
   │ Ctrl+S
   ▼
Auto-upload
   │
   ▼
/var/www/devB
   │
   ▼
devB.example.com

This is intentionally fast.

Git is used when you need to hand development back to the remote Antigravity worker—not as a requirement for every local edit.

Going Away From Your Computer

Suppose you are going to the beach tomorrow. Before leaving, commit your local work:

git add .
git commit -m "Current local work"
git push

Now the remote server can continue from exactly where you left off. From Tahcia, tell Antigravity:

git pull then delete the page Z.

Antigravity pulls your latest local work into: /var/www/devA and continues from there. You can now develop remotely from Tahcia.

The Handoff

The workflow is deliberately symmetrical.

Computer → Tahcia

Local IDE
   │
   │ git commit
   │ git push
   ▼
Git
   │
   │ git pull
   ▼
Antigravity
   │
   ▼
/var/www/devA
   │
   ▼
devA.example.com

Tahcia → Computer

Antigravity
   │
   │ git commit
   │ git push
   ▼
Git
   │
   │ git pull
   ▼
Local IDE
   │
   ▼
devB.example.com

The same Git repository connects both sides.

Why devA and devB Are Separate

The two virtual hosts give you two useful states:

devA.example.com
    ↓
/var/www/devA
    ↓
CURRENT AI WORKING TREE

and:

devB.example.com
    ↓
/var/www/devB
    ↓
LAST PUBLISHED VERSION

This means you can tell Antigravity:

Change the application.

Then immediately inspect:

devA.example.com

without replacing the version you consider stable.

Once satisfied:

commit → publish

and devB.example.com catches up.

Apache Virtual Hosts

The two domains should point to different document roots.

Conceptually:

<VirtualHost *:80>
    ServerName devA.example.com
    DocumentRoot /var/www/devA
</VirtualHost>

<VirtualHost *:80>
    ServerName devB.example.com
    DocumentRoot /var/www/devB
</VirtualHost>

The exact Apache configuration depends on your server, application, HTTPS setup, PHP configuration, and framework.

The important requirement is simply:

devA.example.com  → /var/www/devA
devB.example.com → /var/www/devB

Publishing

A simple publish_to_devB.sh can copy the approved working tree into the published document root.

For example:

#!/bin/bash

set -e

SOURCE="/var/www/devA"
DEST="/var/www/devB"

# Add project-specific copy rules here.
# Example:
rsync -a --delete \
  --exclude=".git" \
  "$SOURCE/" "$DEST/"

Make it executable:

chmod +x /var/www/devA/publish_to_devB.sh

The publishing script should contain the project's actual copy rules.

For applications with generated builds, assets, configuration files, or multiple directories, customize the script accordingly.

Recommended Antigravity Instruction

Give the worker a simple rule:

Work in /var/www/devA.

devA.example.com always reflects the current working tree.

When asked to make changes:
1. Inspect the existing code.
2. Make the changes in /var/www/devA.
3. Test the changes.
4. Do not publish automatically unless instructed.
5. When the user approves the changes, commit them to Git.
6. Run publish_to_devB.sh when the user asks to publish.

This gives you a clean distinction between:

working

and:

approved + published

The Result

You now have one development environment that can be controlled from either side:

                  ┌─────────────────────┐
                  │         Git         │
                  └──────────┬──────────┘
                             │
              ┌──────────────┴──────────────┐
              │                             │
       YOUR COMPUTER                    REMOTE SERVER
              │                             │
       Cursor / VS Code              Tahcia → Antigravity
              │                             │
       tiny changes                  large changes
       rapid iteration               autonomous work
              │                             │
              └──────────────┬──────────────┘
                             │
                        /var/www/devA
                             │
                             ▼
                    devA.example.com
                             │
                       inspect / test
                             │
                         git commit
                             │
                             ▼
                       /var/www/devB
                             │
                             ▼
                    devB.example.com

At your computer, think with Tahcia, use your IDE. Away from your computer, think and code with Tahcia. Git is the handoff between the two. devA is where work happens. devB is what you have published.