Instance access: Session Manager commonly starts as ssm-user. Use sudo -iu ubuntu before commands documented for the buyer account. The API is authenticated and listens on loopback only; it has no browser dashboard.
Store local text documents, ask grounded questions and inspect the exact source text returned by a Haystack pipeline served through Hayhooks. This Software Sushi package includes Haystack 3.4.1, Hayhooks 2.1.0, a document REST adapter and operating-system setup. It is paid repackaged open-source software. Software Sushi is independent of deepset; the software charge covers the packaging and configuration. AWS infrastructure and any model-provider usage are billed separately.
Use a t3.medium or larger x86_64 instance with at least 4 GiB RAM and a 20 GiB root volume. The package uses CPU and needs no GPU. It holds up to 1,000 local text documents, with up to 16,384 characters per document and 100 documents per upload. Retrieval uses BM25 and returns up to three sources. The service rebuilds the retrieval index from SQLite for each query, so it suits small document collections. It is a single-instance service; arrange backups and availability for your workload.
Connect and run your first query
For Systems Manager Session Manager, attach an instance profile with AmazonSSMManagedInstanceCore permissions and outbound endpoint access. The session starts as ssm-user; use sudo -iu ubuntu for customer commands. Alternatively connect with SSH as ubuntu using your own key and approved administrative network. The enabled haystack.service starts automatically. Configuration and API access identity are generated separately on each instance. Port 1416 listens only on 127.0.0.1; this is an authenticated JSON REST API. There is no bundled browser UI.
sudo cloud-init status --wait
sudo -iu ubuntu sushi-haystack status
sudo -iu ubuntu bash /opt/sushi/docs/demo.shThe demo stores two synthetic documents, queries the Aurora retention window, requires the exact source stating 37 days, saves the response and document hashes under ~/haystack-results/, and rereads those documents through the API. The default run uses local retrieval and makes no model request. It prints its result folder and SUSHI_CUSTOMER_DEMO_PASSED only after the checks pass.
Check readiness or verify an existing result using the manifest path printed in the result folder:
sushi-haystack status
sushi-haystack read ~/haystack-results/e2e/manifest.jsonThe e2e path above applies when you explicitly used sushi-haystack demo --output ~/haystack-results/e2e. Normal demo runs create a new uniquely named folder.
Store and query your own text
Run the following as ubuntu. It loads the local client configuration directly and does not print the API token:
import json
from pathlib import Path
from urllib.request import Request, urlopen
config = json.loads(Path('/etc/haystack/client.json').read_text())
def run(payload):
request = Request(
config['base_url'] + '/documents/run',
data=json.dumps(payload).encode(),
headers={'Authorization': 'Bearer ' + config['api_token'],
'Content-Type': 'application/json'},
)
with urlopen(request, timeout=65) as response:
body = json.load(response)
return body.get('result', body)
print(run({'operation': 'upsert', 'documents': [
{'id': 'operations-guide', 'content': 'Aurora retention window is 37 days.'}
]}))
print(run({'operation': 'query', 'question': 'What is the Aurora retention window?'}))
print(run({'operation': 'read', 'ids': ['operations-guide']}))POST /documents/run accepts operation: upsert, read or query. Uploads replace documents with the same ID atomically. IDs use letters, numbers, underscores, dots or hyphens, up to 128 characters. Queries accept question and optional generate: true; returned sources contain IDs, exact content and BM25 scores. GET /status and GET /openapi.json also require Bearer authentication. Requests are limited to 2 MiB. Deployment, undeployment, chat, tracing and other upstream HTTP routes are unavailable in this package. Install operator-reviewed pipeline changes through the filesystem, then restart the service.
Use a model you supply
No model weights, provider credentials or model allowance are included. Local retrieval works before provider setup. To generate answers, configure an OpenAI-compatible chat completions endpoint and a model you have rights to use. The endpoint must support temperature, max_tokens and the /chat/completions API. A local provider must bind to a port other than 1416. Remote providers must use HTTPS.
Edit /etc/haystack/config.json with sudoedit in an unrecorded administration session. Set the provider object's base_url to your endpoint's API base ending in /v1, model to your exact model identifier and api_key to your provider credential. Preserve api_token and state_dir. Leave file ownership root:haystack and mode 0640. Do not paste credentials into shell commands, user-data or shared logs.
sudo systemctl restart haystack.service
sudo -iu ubuntu bash /opt/sushi/docs/demo.sh --generateThat command uses your provider, requires the answer to contain 37 and cite the fixture document ID, then saves and independently rereads the source evidence. Queries with generate: true send retrieved document content and your question to your chosen provider. Review its data handling and charges first. Answers can be wrong even when they contain citations; inspect the returned sources. No deepset commercial platform, enterprise support, durable job execution or Redis deployment is bundled.
Access from your workstation
Use a tunnel instead of opening an inbound API port. The login banner supplies the connection details for this instance.
For Session Manager, the login banner supplies this instance's port-forward command. Use the AWS-StartPortForwardingSession document with guest and local ports both set to 1416. The REST service still requires its per-instance Bearer token. Read /etc/haystack/client.json only through your authenticated administration session and store any workstation copy with mode 0600; never print it into a recording. The banner and customer helper do not reveal it.
Persistence, backup and recovery
Documents live in /var/lib/haystack/documents.sqlite3; the service uses SQLite WAL transactions. They survive application restarts and instance reboots. Model responses and demo evidence live in the selected ubuntu result folder. In-flight requests are not resumed after a process failure. Protect the EBS volume from deletion and arrange backups separately.
For a consistent filesystem backup, stop haystack.service, copy the complete /var/lib/haystack directory and the two configuration files under /etc/haystack using your approved encrypted backup procedure, then start the service. Preserve ownership and permissions when restoring: state is haystack:haystack mode 0750, service configuration is root:haystack mode 0640, and client configuration is root:ubuntu mode 0640. Treat both configuration files as secrets. Keep api_token equal in both files.
For recovery, use sudo systemctl status haystack.service and sudo journalctl -u haystack.service. Configuration is retained on restart. If repeated restarts hit the service rate limit, inspect the journal, wait five minutes, and try once after correcting the cause. Do not delete configuration or the SQLite database to repair a failed request. HTTP 401 means the client identity differs; HTTP 409 means documents or provider configuration are missing or the document limit was reached; HTTP 422 means invalid input; HTTP 502 means the provider call failed. Correct the endpoint/model/credential or input, then retry. Retrieval remains available when the provider is unavailable.
Original package wheels and source archives are retained under /opt/haystack/wheels and /opt/haystack/sources. License texts and notices are under /usr/share/doc/haystack. Haystack and Hayhooks use Apache-2.0; dependencies retain their own licenses. Upstream documentation: Haystack and Hayhooks.
For AMI packaging and setup questions, contact info@softwaresushi.com. Upstream enterprise support is not included.